Req #72655 [NEW]: How to speed up hashing between 40% and 50%

From: Date: Fri, 22 Jul 2016 22:50:14 +0000
Subject: Req #72655 [NEW]: How to speed up hashing between 40% and 50%
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-202516@lists.php.net to get a copy of this message
From: simonhf at gmail dot com Operating system: Irrelevant PHP version: 7.0.9 Package: Strings related Bug Type: Feature/Change Request Bug description:How to speed up hashing between 40% and 50% Description: ------------ I saw that the hash function is a relatively old byte by byte hash function. Newer hash functions like murmurhash3 work on multiple bytes at a time and are therefore faster for bigger strings hashed. I instrumented the existing hash function to capture each string hashed. When running php -v then about 8000 strings were captured. They were all under 39 bytes long. When racing the existing hash function against mmh3 then they are about the same, and the only advantage is that mmh3 would go faster if the strings were longer... which they are not. However, if I pad out the 8000 real world strings to the next 16 bytes and re-race then mmh3 is about 40% to 50% faster than the existing hash algorithm. Why does mmh3 do better this time? Because it works much faster on blocks of 16 bytes. It processes any tail of up to 15 bytes, byte by byte still. By padding out the 8000 real world strings to the next 16 bytes then mmh3 never had to run its byte by byte tail code and is therefore much faster. This got me to thinking that if PHP internals were changed to pad all strings to the next 16 byte boundary and use mmh3 instead then wouldn't this lead to a measurable run-time performance increase in exchange for a slight run-time memory increase? [1] https://github.com/php/php-src/blob/PHP-7.1/Zend/zend_string.h#L325 Test script: --------------- Key,value store is a little faster, memory is a little bigger. -- Edit bug report at https://bugs.php.net/bug.php?id=72655&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=72655&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=72655&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=72655&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=72655&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=72655&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=72655&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=72655&r=needscript Try newer version: https://bugs.php.net/fix.php?id=72655&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=72655&r=support Expected behavior: https://bugs.php.net/fix.php?id=72655&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=72655&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=72655&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=72655&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=72655&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=72655&r=dst IIS Stability: https://bugs.php.net/fix.php?id=72655&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=72655&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=72655&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=72655&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=72655&r=mysqlcfg

« previous php.bugs (#202516) next »