Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:1858 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26387 invoked from network); 21 May 2003 15:49:58 -0000 Received: from unknown (HELO mail.zend.com) (192.117.235.230) by pb1.pair.com with SMTP; 21 May 2003 15:49:58 -0000 Received: (qmail 1859 invoked from network); 21 May 2003 15:49:48 -0000 Received: from localhost (HELO zeev-laptop.zend.com) (127.0.0.1) by localhost with SMTP; 21 May 2003 15:49:48 -0000 Reply-To: zeev@zend.com Message-ID: <5.1.0.14.2.20030521184213.0446ec90@localhost> X-Sender: zeev@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 21 May 2003 18:49:47 +0300 To: Sterling Hughes Cc: internals@lists.php.net,andi@zend.com In-Reply-To: <1053524019.2177.35.camel@hasele> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: zend_fast_hash From: zeev@zend.com (Zeev Suraski) References: <1053524019.2177.35.camel@hasele> Can you explain how it is simpler? :) Writing a lightweight hash has been on our mind for quite some time, but the reason it never happened is that it appears that most of the places that use hashes actually do take advantage of the non-bare-bones features. The biggest difference I can spot is that there's no linked list that links all of the elements. But if we end up adding apply, and clean (which are actually used a lot outside the scope of symbol tables), and soon enough we'd also need merge, copy and unnamed elements - I'm not sure it's worth the trouble of having two different APIs. Feel free to convince us :) Zeev At 16:33 21.05.2003, Sterling Hughes wrote: >Hi, > >I've implemented a very lightweight, efficient hash table for zend >engine 2. This is a table that's appropriate for usage in many of the >areas where then Zend hash table implementation is unnecessarily complex >(which is pretty much everywhere except for PHP arrays themselves.) > >I've attached the implementation, and a patch which integrates the new >hashtable implementation with Zend, including a "case-study," where I've >converted over EG(included_files) to use the new hashtable >implementation. Right now the hash table code is very simple, as its >just there for initial perusal, it can of course be improved upon. > >So, when can I integrate it? ;-) > >-Sterling > >-- >"A business that makes nothing but money is a poor kind of business." > - Henry Ford > >