2 ms·

Odds are someone who writes an app is doing it in a sterile environment, where there are only going to be a handful of test files in any folders. If they do tr

Odds are someone who writes an app is doing it in a sterile environment, where there are only going to be a handful of test files in any folders. If they do try it on their own system, they'll likely discount any performance hits as due to their own hording of files, and not consider the user likely to have just as many, if not more files. Thus, its not likely the programmer will notice it. It's only if some exogenous event causes a programmer to consider run-time performance that it will be measured, and then optimized.

notacoward 4y ago
> there are only going to be a handful of test files Bingo. This used to be a well-known benchmarking cheat, because performance on a full (or even once-full) filesystem can be very different than on a freshly made one. Almost as common as short-stroking, if you remember that. Anybody who wanted realistic results would run tests on a pre-aged filesystem. Cache warming is another example of a similar effect, and there are probably others across every area of computing. It's always really tempting to run tests in a maximally clean environment to get maximally consistent results, but that just doesn't reflect real-world usage.
koyote 4y ago
Another reason could also be the fact that devs usually only ever run development builds of the software. So you end up dismissing slowness due to this ("I am sure this is faster when compiled in Release!"). I've made that mistake before until it was so slow that I decided to compile a Release build which was just as slow and found out that a regression was introduced. Automatic performance monitoring for 'tasks'/services/computations is relatively straightforward but not quite as easy for UI interactions so these often get ignored.