Re: ADT and SPL

php.internals

Zeev Suraski

23 years ago
One issue that's still not finalized is whether the infrastructure that SPL uses (IIRC, opcode overloading) will remain around for the final ZE2. Right now it appears to slow us down significantly (around 10%), and if we won't be able to reduce that overhead, we may rollback to the old execution architecture. We don't know anything for sure yet. Zeev At 09:30 11/05/2003, Sebastian Bergmann wrote:

Sebastian Bergmann

23 years ago
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.
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

Zeev Suraski

23 years ago
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. Zeev

(Marcus Börger)

23 years ago
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