On Tue, Aug 28, 2012 at 6:55 PM, David Harkness <david.h@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Aug 28, 2012 at 4:39 AM, Matijn Woudt <tijnema@xxxxxxxxx> wrote: >> >> First of all, I believe [A] PHP is smart enough to not generate bytecode >> for functions that are not used in the current file. Think about the >> fact that you can write a function with errors, which will run fine >> until you call the function. [B] (except for syntax errors). > > > [B] negates [A]. PHP must either parse the file into opcodes or load them > from APC and further execute the top-level opcodes. That means defining > functions (not calling them unless called directly), constants, global > variables, classes, etc. No amount of measuring is required to tell me that > doing X vs. not doing X in this case clearly takes longer. [B] does not negate [A]. There's a difference between parsing the syntax and defining functions, classes constants and globals, and generating bytecode. In a 'normal' file I guess syntax definitions are only about 5% of the total contents, the rest can be ignored until being called. > > Now, is that time significant enough to warrant the extra logic required? In > my case, absolutely. We organize our library into many classes in multiple > files. By using an autoloader, we simply don't need to think about it. > Include bootstrap.php which sets up the autoloader and include paths. Done. > > In the case with a single 50k library file that is used on 10% of the pages, > I'd absolutely require_once it only in the pages that need it without > measuring the performance. It's so trivial to maintain that single include > in individual pages that the gain on 90% of the pages is not worth delving > deeper. > > Peace, > David > Let me quote the OP, I think that suffices: "When answering this question, please approach the matter strictly from a caching/performance point of view, not from a convenience point of view just to avoid that the discussion shifts to a programming style and the do's and don'ts." - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
