The basket pointer is re-read from the tempstore on every question asked of the cart, so one place click costs four identical key/value reads

BookingCart::resolvePointer() reads the private tempstore every time it is called, and it is the way in to both accessors: current() and activeOrder() call it directly, and heldLines() calls current(). A surface that asks the cart more than one question therefore reads the same key/value row once per question.

PlaceSelectionController::act() asks several: current() to find the order, heldLines() to check the visitor's existing holds, current() again inside the branch that holds the place, and heldLines() once more to build the response. One place click on the graphical map reads tempstore.private.yoyaku_booking_cart four times, for a value that cannot change unless this same class writes it.

Measured

A performance test on the place map, following core's Gander pattern, puts a recurring click (one landing in a basket that already exists) at 25 queries. Four of them are that identical tempstore read:

• 4 x SELECT name, value FROM key_value_expire ... collection = tempstore.private.yoyaku_booking_cart
• 2 x SELECT ... FROM yoyaku_booking WHERE transaction = N, with no state filter
• 2 x SELECT ... FROM yoyaku_booking WHERE transaction = N AND state IN (...)

Why core does not already cache this

PrivateTempStore::get() delegates to DatabaseStorageExpirable::get(), which runs a plain SELECT every call with no static or request cache. That is deliberate on core's part, because the tempstore is shared across requests and another request may have changed it. It argues for the memo rather than against it: four unsynchronised reads inside one request can in principle return four different values, and a request that acts on one basket id throughout is more correct than one that re-asks and may get a different answer halfway through.

Proposed

Memoize the resolved pointer id for the request in BookingCart, invalidated by adopt() and forget(). Those are the only writers of the key and both are on this class, so the memo cannot go stale behind its own back. Expected: 25 to 22 queries per click.

Deliberately out of scope

Memoizing the lines. lineBookings() also runs twice per click and the just-saved booking is reloaded afterwards, but a hold is written in the middle of that request and the response payload has to see it, so a lines memo needs write invalidation. That is a separate and riskier change, noted here rather than folded in.