5 ms·

> I think if you are working at a scale where this is even ridiculously relevant then you will prefer to manually specify required libraries and maintain a clos

by k3n 14y ago

> I think if you are working at a scale where this is even ridiculously relevant then you will prefer to manually specify required libraries and maintain a closer understanding of control flow at all times. I work at a scale where this is extremely relevant, and autoloading is a godsend. Manually including files is not only error-prone, but is tedious and requires development effort [time] that would be best utilized elsewhere. > [...] this particular approach ('autoload') costs too much and delivers too little to be generally praiseworthy Costs too much? Have you not implemented it? It's not hard at all to implement, even if you have an unorthodox file & class naming convention. The only caveat is that you can only have 1 class per file (which hopefully you'd agree is good practice in the first place). Performance increases can be pretty large, too, especially at scale. Consider class A, which in some methods requires access to class B. You _could_ put the include inside those methods, but I can guarantee you that you'll see a noticeable performance hit if that method is called in iteration (we're talking a few seconds worth of time if iterated 1000+ times). That's non-trivial. So, what do you do? You could move it to the top of the file, so that it will only be required once. However, the problem here is you end up with 5-10+ includes at the top of every file. So now when you require that one file, you're now requiring an additional 5-10+ files, each with their own possible set of includes. I've seen instances of needing to require a single file result in having 100+ files being required due to the cascading. With an autoloader, that 100+ goes back to 1. > whilst harming simplcity This couldn't be further from the truth. You will have less LoC overall, less developer time spent trying to get the perfect set of includes so that you only require them once and only when they're needed. You will have fewer bugs due to the problems with manual includes, which again, means more time for developers to actually do stuff that matters.

contingencies 14y ago
> I work at a scale where this is extremely relevant Really? You run Facebook or something? Got any figures? > autoloading is a godsend. Manually including files is not only error-prone, but is tedious and requires development effort [time] that would be best utilized elsewhere. Hang on. How many files are you including? Generally you only need to include one, right. Your framework, maybe an external library. Then you can call in whatever modules you need, as you need them. Right? Or are you using some weird kind of framework without modules? > > [...] this particular approach ('autoload') costs too much and delivers too little to be generally praiseworthy > > [...] whilst harming simplcity > Costs too much? Have you not implemented it? It's not hard at all to implement, even if you have an unorthodox file & class naming convention. The only caveat is that you can only have 1 class per file (which hopefully you'd agree is good practice in the first place). To clarify, the overheads I was referring to were (1) conceptual; less "WTF" for new developers to deal with (2) complexity; code-flow is both simpler and more explicit. > Performance increases can be pretty large, too, especially at scale. Consider... If you can provide some demo code, I'd love to see it. I think you will find largely it's just a result of having a dumb framework or being ultra-contrived in your example to an unrealistic degree. I also think you'll find that second-guessing require_once (a language-level feature) is not going to be faster than simply using it.
- 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

by k3n 14y ago

contingencies 14y ago

> I work at a scale where this is extremely relevant Really? You run Facebook or something? Got any figures? > autoloading is a godsend. Manually including files is not only error-prone, but is tedious and requires development effort [time] that would be best utilized elsewhere. Hang on. How many files are you including? Generally you only need to include one, right. Your framework, maybe an external library. Then you can call in whatever modules you need, as you need them. Right? Or are you using some weird kind of framework without modules? > > [...] this particular approach ('autoload') costs too much and delivers too little to be generally praiseworthy > > [...] whilst harming simplcity > Costs too much? Have you not implemented it? It's not hard at all to implement, even if you have an unorthodox file & class naming convention. The only caveat is that you can only have 1 class per file (which hopefully you'd agree is good practice in the first place). To clarify, the overheads I was referring to were (1) conceptual; less "WTF" for new developers to deal with (2) complexity; code-flow is both simpler and more explicit. > Performance increases can be pretty large, too, especially at scale. Consider... If you can provide some demo code, I'd love to see it. I think you will find largely it's just a result of having a dumb framework or being ultra-contrived in your example to an unrealistic degree. I also think you'll find that second-guessing require_once (a language-level feature) is not going to be faster than simply using it.

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