Hi, Xinchen already tried something similar, but it made PHP slower, because it made access to Bucket->key->h more expensive - two loads with most probably two CPU cache misses instead of one.
Thanks. Dmitry. On Thu, Jan 22, 2015 at 9:43 AM, Benjamin Coutu <ben.co...@zeyos.com> wrote: > Hi, > > Currently a hashtable bucket has to store both, the numeric index "h" and > a potential pointer to a string key "key". > > There is room for improvement here because "h" and "key" are conceptually > mutually exclusive. I therefore propose to unionize "h" and "key" to > effectively save the overhead of having to reserve space for both. > > Now, in order to still be able to distinguish between an integer key and a > pointer to a string key, one could use either of two approaches. > > === 1. Use flags of embedded zval (maybe _zval_struct.u1.v.*) === > > If the is-key-flag is set in the embedded zval then its a string key, if > not then its an integer. This is of course only possible if _zval_struct.u1 > is usable for this (I could not quickly tell). > > === 2. Pointer tagging === > > On a 64/32-bit machine all pointers will be aligned to 8/4 bytes meaning > that their last 3/2 bits will always be zero. We can exploit this to > effectively store information about the pointer in those bits. > > We will use the last bit to distinguish between a pointer and an 63/31-bit > integer, and the second last bit to distinguish between a pointer to a > string key or pointer to the overflowing integer (64/32 bit). Here is a > (8-bit) sample: > > LLLLLLL1: integer (effectively 63/31) > PPPPPP00: pointer to zend_string (string key) > PPPPPP10: pointer to zend_ulong (in case integer key is > 63/31 bit) > > One will then be able to use simple shifting and bitwise operations to > extract the correct meaning. > > Please let me know your thoughts! > > Cheers, > > Ben > > -- > > Benjamin Coutu > Zeyon Technologies Inc. > http://www.zeyos.com > >
