Re: Re: Zend engine's hashtable performance tweaks
| From: | Stas Malyshev | Date: | Fri, 31 Dec 2010 22:19:13 +0000 |
| Subject: | Re: Re: Zend engine's hashtable performance tweaks | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-51177@lists.php.net to get a copy of this message | ||
Hi!
Sorry for no attachments in previous message, I think my attachments weren't redirected with message by lists.php.net email confirmation system. I send them again, and for sure I attach links to public copy of them over HTTP: https://gist.github.com/761094 - php-5.3.4-hashtable-optimization.patch https://gist.github.com/761096 - apc-3.1.6-hashtable-optimization.patchI just took a quick look, so some preliminary notes: 1. +#define ZEND_HASH_SMALL_LOAD_FACTOR_INV 1.75 etc. - maybe makes sense to convert them from floats to couple of integers? I'm not sure if gcc is smart enough not to use floating point here, which would probably be slower than int *7/4. 2. Would it be possible to clean up the patch? There are tons of diffs like this: - HASH_UNPROTECT_RECURSION(ht1); - HASH_UNPROTECT_RECURSION(ht2); + HASH_UNPROTECT_RECURSION(ht1); + HASH_UNPROTECT_RECURSION(ht2); which make no sense and just make it harder to understand what's going on. 3. - ulong h; /* Used for numeric indexing */ + ulong h; why? 4. zend_inline_hash_func - could you describe why you changed it? In any case, it needs some comments, if you deleted the old one, please add description of the new one any why it is better. Will follow up after reading the patch more in depth. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227