Re: ADT and SPL

From: Date: Sun, 11 May 2003 13:14:39 +0000
Subject: Re: ADT and SPL
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-1436@lists.php.net to get a copy of this message
At 10:15 11.05.2003, Zeev Suraski wrote:
At 11:05 11/05/2003, Sebastian Bergmann wrote:
Zeev Suraski wrote:
we may rollback to the old execution architecture
Is there any chance to make the incurred overhead optional (at compile time of PHP, I mean)? This way it could be turned off when there's no extension built-in -- like SPL -- that uses the opcode overloading.
It might be possible, but I'm not sure that it is and that if it is, that we'd want that. It's something that we won't have an answer for for quite some time - profiling this part and figuring out how to speed it up doesn't rank high on our TODO.
During the A'dam conf i was able to track down some speed problems within the engine with Sterling. Several things can be made many things much slower. (i will commit some of the changes today and during the following days). This way i think i can reduce speed decrease to less than 10%. If spl could be integrated into the engine i think i could reduce the speed decrease to 1% (that is what profiling results seem to point out). Another thing i will do is to reduce/remove the spl overhead itself which is also a thing i was pointed to by the profiler. At the moment we seem to have a performance loss of 20% to 45% percent by using spl. This is only at the moment because i haven't optimized the infrastructure i need and used overbloated (for spl) engine features. After moving spl to the engine an optimizing everything i think i can reach what i wanted: using spl is fatser then doing it manually. When moving spl into the engine we are mixing language and compiler features. However this seems to be modern since C# does it too. Furthermore i had a very good idea to speed up the engine even more. But this is not related to spl so i will mail at another place. regards marcus

« previous php.internals (#1436) next »