Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80952 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53697 invoked from network); 22 Jan 2015 06:43:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Jan 2015 06:43:13 -0000 Authentication-Results: pb1.pair.com smtp.mail=ben.coutu@zeyos.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ben.coutu@zeyos.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zeyos.com designates 109.70.220.166 as permitted sender) X-PHP-List-Original-Sender: ben.coutu@zeyos.com X-Host-Fingerprint: 109.70.220.166 unknown Received: from [109.70.220.166] ([109.70.220.166:46416] helo=mx.zeyon.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D4/F0-44026-FFB90C45 for ; Thu, 22 Jan 2015 01:43:12 -0500 Received: from localhost (mx.zeyon.net [127.0.0.1]) by mx.zeyon.net (Postfix) with ESMTP id 3877D5F8EC for ; Thu, 22 Jan 2015 07:43:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mx.zeyon.net Received: from mx.zeyon.net ([127.0.0.1]) by localhost (mx.zeyon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV3Ojh-BEFxb for ; Thu, 22 Jan 2015 07:43:06 +0100 (CET) Received: from cloud.zeyos.com (unknown [109.70.220.163]) by mx.zeyon.net (Postfix) with ESMTPA id 2666C5F8D7; Thu, 22 Jan 2015 07:43:03 +0100 (CET) Date: Thu, 22 Jan 2015 07:43:03 +0100 To: Dmitry Stogov , Xinchen Hui , Nikita Popov , "internals@lists.php.net" MIME-Version: 1.0 X-Mailer: ZeyOS Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Message-ID: <20150122064308.3877D5F8EC@mx.zeyon.net> Subject: [PHP-DEV] Improvements to Hastable Bucket structure From: ben.coutu@zeyos.com (Benjamin Coutu) 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 m= utually exclusive. I therefore propose to unionize "h" and "key" to effecti= vely 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. =3D=3D=3D 1. Use flags of embedded zval (maybe _zval_struct.u1.v.*) =3D=3D= =3D If the is-key-flag is set in the embedded zval then its a string key, if no= t then its an integer. This is of course only possible if _zval_struct.u1 i= s usable for this (I could not quickly tell). =3D=3D=3D 2. Pointer tagging =3D=3D=3D On a 64/32-bit machine all pointers will be aligned to 8/4 bytes meaning th= at their last 3/2 bits will always be zero. We can exploit this to effectiv= ely 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 stri= ng key or pointer to the overflowing integer (64/32 bit). Here is a (8-bit)= sample:=0A=0ALLLLLLL1: integer (effectively 63/31) PPPPPP00: pointer to zend_string (string key)=0APPPPPP10: pointer to zend_u= long (in case integer key is > 63/31 bit) One will then be able to use simple shifting and bitwise operations to extr= act the correct meaning. Please let me know your thoughts! Cheers, Ben --=20 Benjamin Coutu Zeyon Technologies Inc. http://www.zeyos.com