On Thu, Dec 11, 2008 at 12:28 PM, <ceo@xxxxxxxxx> wrote: > > > Inefficiency for me is when it takes longer to code. > > How long can this take? That's why i like PHP. It's very quick to do stuff in, even if arrays are not always the ultimate data structure, they're easy to handle with all the nice functions in PHP... > > > 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. > :-) I wasn't complaining at all. In fact, it was a suggestion to think about. I don't have a problem with someone proving me wrong. In fact, if i would think I was always right, i wouldn't write to a mailing list to hear what other people think. ;-) > > PHP is a scripting language. > Well done. I wasn't aware of that :-) > > > 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 > :-) > OOP has less overhead in development time, which is a lot more expensive than processing time these days. The overhead is O(n). It depends more on your algorithm than on the way you write functions or the PL i think. In fact, in some cases the processing would be quicker to not write a function for a few lines of code. I try to write everything in a function to make it more readable and maintainable, because that is what really counts, i think. > > Not too many device drivers written in C++ > For device drivers performance is more crucial than for end user applications. Each ms or even ns you save in a device driver can save you a multitude in an application (the worse the app code, the more important the performance of the device driver). > > > > 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... Yeah, agree. Whenever i can write a query for something, i do that instead. In this particular case i had at hand however, it was a lot easier to do the things i wanted when the data (after a rather complex query) is in memory. Only maybe up to 20 records which shouldn't be too bad. > > > I know somebody somewhere has some custom PHP extension to prove me wrong, > but that's going to be the exception. What is the exception? To prove you wrong or the PHP extension? :-) > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Tim-Hinnerk Heuer http://www.ihostnz.com
