5 ms·

Your criticism of autoloading comes as a surprise. During 2012 one of my colleagues squeezed a little extra performance out of our software by removing all the

by h2s 14y ago

Your criticism of autoloading comes as a surprise. During 2012 one of my colleagues squeezed a little extra performance out of our software by removing all the calls to require_once from our installation of Zend Framework, thus handing full control to the autoloader. It's a trick that's even mentioned in the official documentation: http://framework.zend.com/manual/1.12/en/performance.classloading.html#performance.classloading.striprequires.sed http://framework.zend.com/manual/1.12/en/performance.classlo.... Apparently it's quicker. Typical bloody PHP.

wvenable 14y ago
It's quicker to only load the files you're actually using for the request. If you explicitly require_once everything, then you're loading every class your application references even if they aren't ever used.
- contingencies 14y ago
  That's right. So like, show me the problem. 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. If not, then you would at least start measuring performance characteristics. When you do that, you will find that if you are pre-loading these things on your last query they will just live in OS filesystem cache (ie. already in memory). (Note: If your load time is disk-affected, a half decent sysadmin could just hard cache your code in memory anyway...) Sure, you will have slightly longer interpreting time (again, not likely to matter, except at huge scale), but that will be offset by things like: (1) Any number of potential caching layers - OS filesystem, APC, etc. - which should maintain these cached either in memory or both in memory as PHP bytecode, thus largely effacing this concern (2) enhanced simplicity for everyone. While I'm all for low-hanging performance fruit, this particular approach ('autoload') costs too much and delivers too little to be generally praiseworthy, whilst harming simplcity. It's justifying itself as optimization, and on many levels it just isn't. It's going backwards.
  - wvenable 14y ago
    > you will prefer to manually specify required libraries and maintain a closer understanding of control flow at all times. Manually specifying the libraries creates the problem in the first place -- it's a very difficult problem when your dependencies have dependencies and so on. You have code that depends on resource A but doesn't use resource A on every request; how do you manage something like that manually in a huge project? > Sure, you will have slightly longer interpreting time If you have a large framework almost everything depends on everything else. So you end up loading and interpreting 100% of your framework on every request. Even worse, you load it all at the start of the request! If you code only uses a small fraction, lets say 20%, of the framework and only loads and interprets it on demand that will make a difference. > While I'm all for low-hanging performance fruit, this particular approach ('autoload') costs too much and delivers too little to be generally praiseworthy, whilst harming simplcity. I don't much care about the performance considerations but I find autoloading far simpler than manually specifying every dependency. In fact, most modern languages don't bother with that either -- going back to C/C++ from Java/C# gives the same sort of pain. I'm not sure why you think it "costs too much" given it's likely to cost less in performance and code written. Performance was not the main concern for the addition of autoloading.
  - 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.
thelarry 14y ago
Zend is kind of bloated and tries giving you the world when you only need a form parser. require_once is also "slow" because it checks the list of required files each time you call require_once to make sure you aren't requiring the same file twice. It makes sense to stay away from that with a framework like Zend where it just wants to include so many files. With your typical app, not using require_once and only using require probably doesn't save much time
contingencies 14y ago
It was only an example. Your commend ignores a programming fundamental: "premature optimization is the root of all evil". Clarity and simplicity for the programmer trump performance every time. Only in extreme cases, worry about it later, and don't use that as an excuse to break things for the rest of us.
- jasonlotito 14y ago
  > premature optimization is the root of all evil Most misunderstood quote of programming. Premature is the qualifier.
  - contingencies 14y ago
    When it's right to optimize: when (a) everything works, and (b) performance has become a meaningful cost, making it the most important issue to work on. When it's right to care about simplicity and clarity: absolutely all the time.
    - jasonlotito 14y ago
      > When it's right to optimize: when (a) everything works, and (b) performance has become a meaningful cost, making it the most important issue to work on. Incorrect. There are things people do all the time with the understanding of mature optimization techniques. We know, for example, that certain algorithms perform better then a simple brute force technique, so we start there We might test various algorithms, too, before everything works. But we are testing. Premature is not about time. It's about effectiveness. Sometimes you cannot gauge effectiveness until everything works, sure. But often times this is not the case.
      - contingencies 14y ago
        > Incorrect I'm not denying there's better code and worse code in a performance-measurable sense that's written before 'optimization' goes on later in a project. However, in the real world, we deal with problems. If you have a performance characteristic that's causing issues and you can reproduce it, then you have a problem and you can work on it. The inverse is also true. Point of premature optimization quote: Most of the time more than a passing / higher-level-architectural thought about performance is not a good idea.

by h2s 14y ago

wvenable 14y ago

It's quicker to only load the files you're actually using for the request. If you explicitly require_once everything, then you're loading every class your application references even if they aren't ever used.

contingencies 14y ago
That's right. So like, show me the problem. 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. If not, then you would at least start measuring performance characteristics. When you do that, you will find that if you are pre-loading these things on your last query they will just live in OS filesystem cache (ie. already in memory). (Note: If your load time is disk-affected, a half decent sysadmin could just hard cache your code in memory anyway...) Sure, you will have slightly longer interpreting time (again, not likely to matter, except at huge scale), but that will be offset by things like: (1) Any number of potential caching layers - OS filesystem, APC, etc. - which should maintain these cached either in memory or both in memory as PHP bytecode, thus largely effacing this concern (2) enhanced simplicity for everyone. While I'm all for low-hanging performance fruit, this particular approach ('autoload') costs too much and delivers too little to be generally praiseworthy, whilst harming simplcity. It's justifying itself as optimization, and on many levels it just isn't. It's going backwards.
- wvenable 14y ago
  > you will prefer to manually specify required libraries and maintain a closer understanding of control flow at all times. Manually specifying the libraries creates the problem in the first place -- it's a very difficult problem when your dependencies have dependencies and so on. You have code that depends on resource A but doesn't use resource A on every request; how do you manage something like that manually in a huge project? > Sure, you will have slightly longer interpreting time If you have a large framework almost everything depends on everything else. So you end up loading and interpreting 100% of your framework on every request. Even worse, you load it all at the start of the request! If you code only uses a small fraction, lets say 20%, of the framework and only loads and interprets it on demand that will make a difference. > While I'm all for low-hanging performance fruit, this particular approach ('autoload') costs too much and delivers too little to be generally praiseworthy, whilst harming simplcity. I don't much care about the performance considerations but I find autoloading far simpler than manually specifying every dependency. In fact, most modern languages don't bother with that either -- going back to C/C++ from Java/C# gives the same sort of pain. I'm not sure why you think it "costs too much" given it's likely to cost less in performance and code written. Performance was not the main concern for the addition of autoloading.
- 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.

thelarry 14y ago

Zend is kind of bloated and tries giving you the world when you only need a form parser. require_once is also "slow" because it checks the list of required files each time you call require_once to make sure you aren't requiring the same file twice. It makes sense to stay away from that with a framework like Zend where it just wants to include so many files. With your typical app, not using require_once and only using require probably doesn't save much time

contingencies 14y ago

It was only an example. Your commend ignores a programming fundamental: "premature optimization is the root of all evil". Clarity and simplicity for the programmer trump performance every time. Only in extreme cases, worry about it later, and don't use that as an excuse to break things for the rest of us.

jasonlotito 14y ago
> premature optimization is the root of all evil Most misunderstood quote of programming. Premature is the qualifier.
- contingencies 14y ago
  When it's right to optimize: when (a) everything works, and (b) performance has become a meaningful cost, making it the most important issue to work on. When it's right to care about simplicity and clarity: absolutely all the time.
  - jasonlotito 14y ago
    > When it's right to optimize: when (a) everything works, and (b) performance has become a meaningful cost, making it the most important issue to work on. Incorrect. There are things people do all the time with the understanding of mature optimization techniques. We know, for example, that certain algorithms perform better then a simple brute force technique, so we start there We might test various algorithms, too, before everything works. But we are testing. Premature is not about time. It's about effectiveness. Sometimes you cannot gauge effectiveness until everything works, sure. But often times this is not the case.
    - contingencies 14y ago
      > Incorrect I'm not denying there's better code and worse code in a performance-measurable sense that's written before 'optimization' goes on later in a project. However, in the real world, we deal with problems. If you have a performance characteristic that's causing issues and you can reproduce it, then you have a problem and you can work on it. The inverse is also true. Point of premature optimization quote: Most of the time more than a passing / higher-level-architectural thought about performance is not a good idea.