On Thursday 14 August 2008 12:36:29 am Rasmus Lerdorf wrote: > Larry Garfield wrote: > > I would also note that "include up front and have a good autoload scheme" > > works great if you are writing all classes. If you're trying to use > > namespaces and functions, there is no autoload. That makes the autoload > > argument moot, and pre-loading everything up front can get ridiculously > > expensive in large systems, and even then you don't always know what to > > load up front. (Think anything that accepts plugins.) So an answer of > > "well if it throws a warning when you do that, don't do that" is simply > > not realistic in practice. > > With an opcode cache, it is actually often more efficient to load > everything up front even if you aren't using it all on any given > request. By using autoload or other conditional mechanisms you lose the > function and class caching mechanism provided by the opcode cache > because you have now pushed the creation of these to the executor > instead of letting the opcode cache cache them for you. > > And assuming your include_path setting and your include hierachy is > clean so you don't have any or at least only minimal per-include stat > overhead, whether you include 1 or 20 files on a request isn't a big > deal since they are all going to be in memory anyway. > > -Rasmus
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"?) Even then, every benchmark I've seen for Drupal (the system I work on) still gives a several-fold increase in runtime performance with an opcode cache, so I am not super worried about eeking out every last CPU cycle. We also by nature have to support user-pluggable modules, which cannot be statically included. There's also memory usage to consider. In our testing, conditional includes sliced 25% off of the memory usage when not using an opcode cache and had no noticeable effect when using an opcode cache, so that's still a big win for larger code bases. We're working at making even more code conditionally included in the next version for that exact reason. In any case, the point I am making is that saying "well, don't use conditional includes and namespaces" or "don't use functions and namespaces" is a non-option. Either of those pretty much guarantees that we (Drupal) will never be able to use namespaces in practice. -- Larry Garfield [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
