4 ms·

This is a documented Zend Framework thing, so personally I wouldn't call it "contrived", "dumb" or "weird". http://till.typepad.com/blog/2008/10/zendframework-

by h2s 14y ago

This is a documented Zend Framework thing, so personally I wouldn't call it "contrived", "dumb" or "weird". http://till.typepad.com/blog/2008/10/zendframework-performance.html http://till.typepad.com/blog/2008/10/zendframework-performan... > Removing require_once in favour of __autoload shows > one of the biggest performance improvements in my > entire application - I shaved off roughly 220 > milliseconds by removing about 15 (or so) calls to > require_once in my bootstrap.php file. And that's > with APC enabled, and a decent sized realpath.cache > (and .ttl). Presumably this lazy loading approach starts being faster once your codebase exceeds a certain size. Everything you've said so far indicates that you tend to work on smaller, fire-and-forget PHP projects, so maybe this just doesn't resonate with your experience and I can certainly respect that. No matter what your gut feeling about language-level features may be, I know that at my day job, we measured a clear performance boost when we removed require_once and switched completely to autoloading. For those of us working on very large, long-term PHP codebases, autoloading really is a good thing and I hope you can respect that in return.

contingencies 14y ago
Good answer. I'm not saying that including code you don't want to use isn't going to shave of milliseconds, I'm just not convinced that the problem is being adequately identified. The problem honestly sounds like the codebase itself. And if that's something built with Zend, then perhaps that doesn't reflect well on Zend's innate structure, and Zend's only effective way around this is through 'autoload'.
- wvenable 14y ago
  > The problem honestly sounds like the codebase itself. Any reasonably sized codebase is going to load a lot of files. Because your projects are so small that this is not an issue is not a reflection on the quality of every one else's work.
  - contingencies 14y ago
    The subject of the conversation: "Given that (a) we need to load files (b) loading files takes time ... do we, consider performance: (1) use an autoloader on some mega-framework; or (2) be explicit and require directly." I feel this comment contributes nothing to the conversation but a baseless personal accusation.
    - wvenable 14y ago
      On the subject of the conversation, we can either let the computer do the work for us or waste time specifying it manually in a way that it's nearly impossible to do as effectively. The code is already explicit enough, requiring directly is pointless busy-work that is more likely to be wrong.

by h2s 14y ago

contingencies 14y ago

Good answer. I'm not saying that including code you don't want to use isn't going to shave of milliseconds, I'm just not convinced that the problem is being adequately identified. The problem honestly sounds like the codebase itself. And if that's something built with Zend, then perhaps that doesn't reflect well on Zend's innate structure, and Zend's only effective way around this is through 'autoload'.

wvenable 14y ago
> The problem honestly sounds like the codebase itself. Any reasonably sized codebase is going to load a lot of files. Because your projects are so small that this is not an issue is not a reflection on the quality of every one else's work.
- contingencies 14y ago
  The subject of the conversation: "Given that (a) we need to load files (b) loading files takes time ... do we, consider performance: (1) use an autoloader on some mega-framework; or (2) be explicit and require directly." I feel this comment contributes nothing to the conversation but a baseless personal accusation.
  - wvenable 14y ago
    On the subject of the conversation, we can either let the computer do the work for us or waste time specifying it manually in a way that it's nearly impossible to do as effectively. The code is already explicit enough, requiring directly is pointless busy-work that is more likely to be wrong.