> Am 28.10.2015 um 05:20 schrieb Dmitry Stogov <dmi...@zend.com>:
> What is the general impression from the patch?
> Should we commit it (with minor fixes and/or additional optimisations)?
> Bob, do you see performance improvement on your app?
> 
> Thanks. Dmitry.
> 
> On Oct 27, 2015 4:14 PM, "Dmitry Stogov" <dmi...@zend.com 
> <mailto:dmi...@zend.com>> wrote:
> Hi,
> 
> Please take a look: https://github.com/php/php-src/pull/1604 
> <https://github.com/php/php-src/pull/1604>
> The speed improvement on real-life is insignificant.
> VM size is increased by 10KB.
> 
> I don't have a strong opinion, if this should go into master or not.
> 
> Thanks. Dmitry.

In general I like the patch, if only for the reason that it splits up the 
monster zend_fetch_var_address_helper actually was into two helpers…

I benchmarked https://github.com/amphp/aerys/blob/master/lib/HPack.php with the 
following code:

// Two example request headers from RFC 7541
$data1 = hex2bin(str_replace(" ", "", "8286 8441 8cf1 e3c2 e5f2 3a6b a0ab 90f4 
ff"));
$data2 = hex2bin(str_replace(" ", "", "8286 84be 5886 a8eb 1064 9cbf"));

for ($i = 0; $i < 1e5; $i++) {
    $obj = new HPack;
    $obj->decode($data1);
    $obj->decode($data2);
}

and got 6.27 vs. 6.01 seconds (4%). With the one or other optimization (like 
mentioned in PR: not doing a zend_fetch_class() on each call, maybe more), 
it'll be probably even more.

(I realize there's a lot overhead, but that's because I try to have a not too 
synthetic benchmark; but at least these methods are the bottleneck of most 
HTTP/2 traffic in this server app, so, if I can speed these up, it will be 
significant.)

Bob

Reply via email to