There are a few times when a cursor needs to store a key.  For example, in cursor->set_key we need to copy the callers key because it might exist in caller's temporary storage and might be overwritten by the time the cursor needs to use it.  Also, cursor->get_key may copy from the on-page key.  The cursor also contains an upper and lower bound key that is set via the cursor->bound calls.  All of these are stored as WT_ITEMs, and allocated or grown as needed.  This can mean there may be calls to malloc happening in performance paths.

For many cases, the application knows the maximum key size, or might know the approximate key size.  We could also deduce it from previous traffic to a btree.  We should think about taking advantage of this.  Even using an educated fixed guess, we might drastically cut down on the number of allocations.

For instance, suppose we added three 20 byte buffers to the btree cursor struct.  When we are about to set the cursor's key, or lower bound or upper bound, if it is under 20 bytes, we store it in the fixed struct, otherwise we do the usual thing.