Hi:

run bench.php:

*before patched:

$ sapi/cli/php Zend/bench.php
simple             0.374
simplecall         0.720
simpleucall        0.600
simpleudcall       0.633
mandel             1.161
mandel2            1.632
ackermann(7)       0.810
ary(50000)         0.108
ary2(50000)        0.098
ary3(2000)         0.699
fibo(30)           2.180
hash1(50000)       0.168
hash2(500)         0.171
heapsort(20000)    0.395
matrix(20)         0.354
nestedloop(12)     0.656
sieve(30)          0.441
strcat(200000)     0.073
------------------------
Total             11.276


*after patched:
sapi/cli/php Zend/bench.php
 simple             0.520
simplecall         0.723
simpleucall        0.622
simpleudcall       0.639
mandel             1.168
mandel2            1.711
ackermann(7)       0.784
ary(50000)         0.116
ary2(50000)        0.100
ary3(2000)         0.749
fibo(30)           2.188
hash1(50000)       0.177
hash2(500)         0.184
heapsort(20000)    0.421
matrix(20)         0.420
nestedloop(12)     0.836
sieve(30)          0.458
strcat(200000)     0.073
------------------------
Total             11.888



thanks


On Thu, Jan 5, 2012 at 4:53 PM, Laruence <larue...@php.net> wrote:
> Hi:
>    the origin thread is too long, so I open a new thread for this.
>
>    I have made another patch try to fix this issue.
>
>    the key point is, randomizing the table size(tableMask).
>
>    instead of double the the table size in zend_hash_do_resize,  I
> increase the table size with a random delta ( the value now is just a
> try,  we can change it to a more appropriate value),
>  that is:  new_table_size = old_table_size * 2 + random_num.
>
>    then,  the collision can not be predicatible, which fix the
> problem,  and also fixed the issue in json/soap/serialize etc.
>
>    here is the patch(draft now):
> https://bugs.php.net/patch-display.php?bug_id=60655&patch=rand_hash_resize.patch&revision=latest
>
>    after this fix , may slow down the php, but compared to the
> security threat I thinks the cost could be ignored.
>
>    for the test script list in
> http://nikic.github.com/2011/12/28/Supercolliding-a-PHP-array.html:
>
>    *before patched:
>        Inserting 65536 evil elements took 162.65940284729 seconds
>        Inserting 65536 good elements took 0.075557947158813 seconds
>
>    *after  patched:
>        Inserting 65536 evil elements took 0.074128866195679 seconds
>        Inserting 65536 good elements took 0.091044902801514 seconds
>
>    what do you think ?
>
> thanks
>
> --
> Laruence  Xinchen Hui
> http://www.laruence.com/



-- 
Laruence  Xinchen Hui
http://www.laruence.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to