5 ms·

Re: your last paragraph. I tend to do something similar in the form of comments. I'll use what is most likely horribly inefficient (but quick and easy to reaso

Re: your last paragraph. I tend to do something similar in the form of comments. I'll use what is most likely horribly inefficient (but quick and easy to reason about) way of doing things, then i'll throw a comment in the docblock about how it's probably pretty inefficient. My reasoning is that i've had parts of a program that were very lightly used become very heavily used as the program evolves, and taking a few seconds to comment that this is a low hanging fruit if i need it has helped future-me at least once. As with most things, it's not a hard "rule", just something I'll do when it makes sense.

mattmanser 10y ago
Why bother? The comment is a waste of time. Performance profile it and go from there. If you're doing anything other than using a performance profiling tool on real code with vaguely realistic data you're completely and utterly wasting your time taking stabs in the dark. Leaving comments that will become obsolete and misleading as the code evolves seems just as bad as pre-optimizing code. I've been working on a project at the moment where exactly what you've suggested was done, but they'd used todo comments. Last winter they'd had to up to an azure large SQL instance and it'd still max out DTU every now and again (DTU being MS's db performance measure on azure). Client was hoping I might fix a couple more problems as the volume is expected to triple or more this winter. In 6 days of simply running a local profiler I found and fixed 3 major performance problems, none in any way related to the pointless comments claiming X method needed optimising, none of which were even 1/10000th of the program's execution time. One of those problems was even caused by a previous "optimisation". I confirmed the problem spots by checking the web logs and avg page response times to confirm production was having the same problems. The site now potters along on a small SQL instance never going above 5% DTU, the worst pages are all being served 5 times faster. Done the same thing to a site with slow rendering (js problems). Chrome's profiler is good enough. If you don't know how to use your language's profiler, learn, now.
- Klathmon 10y ago
  Don't get me wrong, I do use the profiler a ton, and it's the first thing i reach for when i start noticing issues, but having that little comment about why i did it that way lets me relax a bit. I'd never mark it as a TODO or something that would clutter a tool up with crap, but having it there could help. A comment out of something I did recently where it's a loop that iterates over an array that's expected to be a few hundred long, and each iteration loops over the array again: // This is O(n^2) out of pure laziness. Might cause issues if the array gets really big. It's not hurting anyone, took like 10 seconds to write, and if it ever becomes a problem, the first thing i'll see is that in the function docblock which lets me (or someone else) know that there is no technical reason it needed to be O(n^2).
  - tlarkworthy 10y ago
    Profilers help identify hot spots, but don't really explain the dynamic behaviour of why something is a hot spot. So comments saying that something is O(n^2) when it could be O(n) is very helpful when you see the inner function hogging 90% of resources. Profilers don't get complexity classes.
    - mattmanser 10y ago
      Not really, comments like this are often wrong or misleading. After all, the programmer hasn't actually tested anything, they're just making assumptions. Otherwise they'd have actually fixed it. It's just pointless noise. A profiler will tell you that a particular function was run 10,000 times costing 0.5ms per run. You're not going to have a problem tracking down the problem, the comment won't help.
  - macspoofing 10y ago
    >// This is O(n^2) out of pure laziness. Might cause issues if the array gets really big It just feels lazy. You're passing the buck to another dev who may be working on the code, weeks, months or years down the line. What are they supposed to do about it? Randomly rewrite working code and risk introducing a bug? If you think the input might reasonably scale to a size that will cause an issue then do some preemptive defensive coding and fix it. Otherwise don't. Stand by your decision. TODOs and FIXMEs tend to linger and get ignored. If I'm looking for performance problems, I'm not scanning for source code TODOs. I load a profiler and I'll see which methods take too much time.
yid 10y ago
> and taking a few seconds to comment that this is a low hanging fruit if i need it has helped future-me at least once. The problem with "fruit" like this is that it depends heavily on the exact version of the JS runtime being used. If the next iteration of V8 introduces an automatic optimization or (worse) de-optimization for your low-hanging fruit, you're left with sometimes odd-looking code for a behavior that no longer exists. As we've learned from the history of C++, if you depend on undefined/undocumented behavior quirks of a compiler or runtime, you're going to have a bad time. It's better to bump micro-optimizations like this down to a lower-level language. At best, you're buying a constant factor in whatever scaling curve you're trying to beat.
- Klathmon 10y ago
  I'm not talking about JIT tricks or JS engine quirks, but more like "Heads up, this function is O(n^2) because i'm lazy"
jononor 10y ago
Same, I'll throw in "// PERF: foo" comments for future. I like it because don't have to think about it anymore if it is written down: I've made a choice to not prematurely optimize it, documented this fact and any potential nugget of insight I might have had that could maybe help in the future. The peace of mind / keeping in the flow is the most important.
- macspoofing 10y ago
  >I like it because don't have to think about it anymore if it is written down ... The peace of mind / keeping in the flow is the most important. Exactly. It's lazy. Let the guy down the road deal with it.
  - drtz 10y ago
    One coder's "lazy" is another Engineer's tradeoff of efficiency for design simplicity and development resources.

mattmanser 10y ago

Why bother? The comment is a waste of time. Performance profile it and go from there. If you're doing anything other than using a performance profiling tool on real code with vaguely realistic data you're completely and utterly wasting your time taking stabs in the dark. Leaving comments that will become obsolete and misleading as the code evolves seems just as bad as pre-optimizing code. I've been working on a project at the moment where exactly what you've suggested was done, but they'd used todo comments. Last winter they'd had to up to an azure large SQL instance and it'd still max out DTU every now and again (DTU being MS's db performance measure on azure). Client was hoping I might fix a couple more problems as the volume is expected to triple or more this winter. In 6 days of simply running a local profiler I found and fixed 3 major performance problems, none in any way related to the pointless comments claiming X method needed optimising, none of which were even 1/10000th of the program's execution time. One of those problems was even caused by a previous "optimisation". I confirmed the problem spots by checking the web logs and avg page response times to confirm production was having the same problems. The site now potters along on a small SQL instance never going above 5% DTU, the worst pages are all being served 5 times faster. Done the same thing to a site with slow rendering (js problems). Chrome's profiler is good enough. If you don't know how to use your language's profiler, learn, now.

Klathmon 10y ago
Don't get me wrong, I do use the profiler a ton, and it's the first thing i reach for when i start noticing issues, but having that little comment about why i did it that way lets me relax a bit. I'd never mark it as a TODO or something that would clutter a tool up with crap, but having it there could help. A comment out of something I did recently where it's a loop that iterates over an array that's expected to be a few hundred long, and each iteration loops over the array again: // This is O(n^2) out of pure laziness. Might cause issues if the array gets really big. It's not hurting anyone, took like 10 seconds to write, and if it ever becomes a problem, the first thing i'll see is that in the function docblock which lets me (or someone else) know that there is no technical reason it needed to be O(n^2).
- tlarkworthy 10y ago
  Profilers help identify hot spots, but don't really explain the dynamic behaviour of why something is a hot spot. So comments saying that something is O(n^2) when it could be O(n) is very helpful when you see the inner function hogging 90% of resources. Profilers don't get complexity classes.
  - mattmanser 10y ago
    Not really, comments like this are often wrong or misleading. After all, the programmer hasn't actually tested anything, they're just making assumptions. Otherwise they'd have actually fixed it. It's just pointless noise. A profiler will tell you that a particular function was run 10,000 times costing 0.5ms per run. You're not going to have a problem tracking down the problem, the comment won't help.
- macspoofing 10y ago
  >// This is O(n^2) out of pure laziness. Might cause issues if the array gets really big It just feels lazy. You're passing the buck to another dev who may be working on the code, weeks, months or years down the line. What are they supposed to do about it? Randomly rewrite working code and risk introducing a bug? If you think the input might reasonably scale to a size that will cause an issue then do some preemptive defensive coding and fix it. Otherwise don't. Stand by your decision. TODOs and FIXMEs tend to linger and get ignored. If I'm looking for performance problems, I'm not scanning for source code TODOs. I load a profiler and I'll see which methods take too much time.

yid 10y ago

> and taking a few seconds to comment that this is a low hanging fruit if i need it has helped future-me at least once. The problem with "fruit" like this is that it depends heavily on the exact version of the JS runtime being used. If the next iteration of V8 introduces an automatic optimization or (worse) de-optimization for your low-hanging fruit, you're left with sometimes odd-looking code for a behavior that no longer exists. As we've learned from the history of C++, if you depend on undefined/undocumented behavior quirks of a compiler or runtime, you're going to have a bad time. It's better to bump micro-optimizations like this down to a lower-level language. At best, you're buying a constant factor in whatever scaling curve you're trying to beat.

Klathmon 10y ago
I'm not talking about JIT tricks or JS engine quirks, but more like "Heads up, this function is O(n^2) because i'm lazy"

jononor 10y ago

Same, I'll throw in "// PERF: foo" comments for future. I like it because don't have to think about it anymore if it is written down: I've made a choice to not prematurely optimize it, documented this fact and any potential nugget of insight I might have had that could maybe help in the future. The peace of mind / keeping in the flow is the most important.

macspoofing 10y ago
>I like it because don't have to think about it anymore if it is written down ... The peace of mind / keeping in the flow is the most important. Exactly. It's lazy. Let the guy down the road deal with it.
- drtz 10y ago
  One coder's "lazy" is another Engineer's tradeoff of efficiency for design simplicity and development resources.