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:
Hey,
why not merge ADT into SPL? IMHO the abstract data types "belong" into
the SPL and having only one extension for these would be nice, too.This was something I forgot to discuss with Marcus and Sterling in
Amsterdam.--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
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/
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
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