Re: Inconsistencies in 5.3

On Thursday 14 August 2008 2:08:23 am Stan Vassilev | FM wrote: > >> For better or worse 99% of the code I write runs on systems without an > >> opcode > >> cache 99% of the time so that's what I optimize for. That it is > >> apparently > >> impossible to optimize for both opcode caching and non-opcode caching > >> environments at the same time (the former hates conditional include, the > >> latter loves it) is a problem in itself, although I will be honest that > >> I have never fully understood the reasons for it. (Doesn't the opcode > >> cache > >> just recognize "oh yeah, file /foo/bar/baz.php, I've got that parsed > >> already > >> I'll just add that to the runtime environment"?) > > > > No, it also takes all top-level functions and classes and caches the > > created functions and classes in shared memory and modifies the cached > > opcodes to not need to create these at execution time. However, it > > obviously can't do this if the execution context is required in order to > > know whether the function or class should exist on that request, so > > whenever you do any sort of conditional function or class definition you > > lose this level of caching. > > > > -Rasmus Hm, I see. So you still get the cached compiled opcodes, but not the cached "linking". (To use C++ terminology, which I'm sure is technically inaccurate in this case.) Thanks. > Hi, > > This is why it pays to have two automated distribution models. For > deployment with no opcode cache, and for development/version control, an > autoloader using a class map is most practical. > > An automated packer can take all classes and functions (or part of them in > common use) and put them in the bootstrap file for opcode deployment, > leaving only the less common to autoload. > > (And which makes the fact we can now have multiple namespaces in one file > really important) > > Regards, > Stan Vassilev Not looking to start a flame war, really, but how do the above opcode concerns impact Phar? (I mention that here because it was discussed as a potential alternative to multiple namespaces per file to avoid the many-stats problem.) -- Larry Garfield larry@garfieldtech.com