Re: usort for sorting an array of objects
| From: | ceo at l-i-e dot com | Date: | Wed, 10 Dec 2008 23:28:25 +0000 |
| Subject: | Re: usort for sorting an array of objects | ||
| Groups: | php.general | ||
| Request: | Send a blank email to php-general+get-284443@lists.php.net to get a copy of this message | ||
> Inefficiency for me is when it takes longer to code.
How long can this take?
Even if you go full-blown with an Interface and static methods that have to be fleshed out in the
implementations, you're still talking about an hour or so.
Quit complaining and start typing.
:-)
> PHP is a scripting language.
> Everytime the compiler has to parse the source.
No.
The source is compiled once, and your callback is a PHP function pointer passed down to the C
function for usort.
That C function has to call back out to the PHP function pointer.
That is "slow" compared to a all native C, perhaps, but it's not re-compiling your
PHP source function on every call to the compare function.
Even if you are comparing across script calls, APC or ZendCache or similar will compile once.
The slowness isn't even in the compiling anyway, really. It's in hitting the disk drive
to LOAD the PHP source.
It's just as easy to cache the parsed byte-code as it is the source, and it saves a few more
cycles, so the caches store the byte-code; But the real savings is not hitting the hard drive to get
the PHP source.
> You can not except true OOP performance.
If you REALLY want performance, OOP has enough overhead that you can re-factor to strictly
procedural or functional and squeeze out a bit more :-)
Not too many device drivers written in C++
> OOP behavior is okay.
> If performance is the main factor, an C extension will do that.
If you're sorting anything large enough for performance to be the main factor, it probably
belongs in a database, actually...
I know somebody somewhere has some custom PHP extension to prove me wrong, but that's going to
be the exception.