On Tue, Nov 2, 2010 at 9:57 AM, Lester Caine <les...@lsces.co.uk> wrote:
> Derick Rethans wrote: > >> Actually, Kalle just pointed out that it compiles just fine. In that >> case, I think we should put it in trunk and in the 5.4 alpha. >> > > As long as it is disabled by default and can easily be replaced by > preferred alternatives ... eaccelerator is still working fine now that it > has been upgraded to handle 5.3 ... although it would be nice to see some > more up to date comparisons. Although I suspect in reality, the combination > with database and other caching activity means that a straight comparison > may be a little meaningless? Change the database and the figures are going > to be different anyway ... so a straight comparison on non-database code > would be a little more practical. > +1. Being disabled by default was agreed on for "old 6.x" so should be for 5.4 as well. However I think there probably is a lot of possibilities for PHP if it was better integrated in the future (lets say "new 6.x"). To offer better autoload performance if you stick to PSR-0 for class autoloading for instance. Hence a future php version that has better persistent knowledge of classes used on the system so every class load doesn't result in a full require call with all its overhead on every request. And/Or a shared api / backend for shared persistent cache for stat calls, real path and parsed php structures, and anything else one might want to let persist between requests in the future. A discussion for another thread some other time off course. > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
