Re: Re: 1 last error to fix before the application is done!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 14, 2008 at 10:29 AM, Colin Guthrie <gmane@xxxxxxxxxxxxxx> wrote:
> Andrew Ballard wrote:
>>
>> I've heard that a lot, but I just don't see it. I'm sure some of you
>> can come up with better tests than this, but here is what I used:
>
> ...
>>
>> Based on these results, I'd hardly use the "language construct versus
>> function call" optimization argument to make my decision. I'm not sure
>> if this is a testament to improvements in the PHP engine over the last
>> couple years, or if equipment has gotten fast enough that the
>> differences have become irrelevant. Quite possibly, it's both.
>
> There are a couple of issues with those benchmarks...
> 1. It uses rand()... this is generally a bad thing in benchmarks

True. I'm not sure how to test it, but I'm curious if there is a bias
toward elements that do or do not exist, so I let it pick values both
in and out of range. I suppose I could have preselected values to be
consistent among all tests.

> 2. It uses internal (wall clock) timing and tests different things in the
> same application run.

I'm on a Windows development machine.

> 3. 50k iterations is easy! Give it something hard :)

I've done the same with 100k or more. The average is the same. If I'm
ever calling either of these functions 100k times in a production
script, I need to rethink the app anyway.

> You should really use an external timing function (like "time blah" on *nix)
> as it shows you real processor time used, as well as wall-clock time.

Again, I'm on Windows and my PHP environment is inside Zend Studio. Is
this something I can see with something like the profiler in Xdebug?
(I have run similar test scripts on the web servers, but they are also
running Windows and I don't have access other than file shares to
where we publish apps.)

> I've posted a simple benchmark else where on this thread that tests which
> prove that for a two index-depth test, !empty is approx 4.5x faster than the
> equiv array_key_exists tests.

I saw that, and for this case I'd agree with you. To be fair, I think
the savings is more due to the difference between calling empty() once
to get the desired result versus calling array_key_exists() twice and
then testing the actual array value (which I'm sure means scanning the
array to get the value and then doing a logical comparison). I will,
however, file this information for later use as it looks useful in
some situations like this one.

> Even for a single depth array test, I still get ~3x speed improvement using
> empty() vs. array_key_exists().


Andrew

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux