3 ms·
But in my experience, that's usually only affecting a small part of a system. If you could save 90% by such optimizations, you're at a very early stage of your
by pvorb 6y ago
But in my experience, that's usually only affecting a small part of a system. If you could save 90% by such optimizations, you're at a very early stage of your application. Otherwise, this would've been spotted earlier. But in a larger system, these things can be around for some time but it's unlikely that fixing them brings an overall performance boost of 90%. More like 3% here, 5% there and so on.
Edit: And I agree: I wouldn't be surprised to find a SELECT * and a call to size() in a moderately sized system.
- t-writescode 6y ago> If you could save 90% by such optimizations, you're at a very early stage of your application. You would be very, very surprised. Speaking from experience.
- qes 6y ago> More like 3% here, 5% there and so on. Ten years working on a code base that serves near-StackOverflow levels of traffic and 5% would be a _huge_ win. I don't come across those, or even 3%, very often. Our app has dozens of routes all seeing hundreds to thousands of requests a minute. To get a performance boost that big it has to be in some foundational code that's used nearly everywhere, and that code's already been poured over every way from Sunday. Occasionally we'll run into a bit of code that sneakily becomes a significant drag on the system as traffic through that code grows slowly over time. A fix might result in a large % load drop, but only because there's some pathological problem, which I hesitate to call an "optimization" rather than a "bug fix". We did also uncover many significant optimizations after migrating from dedicated hosted bare metal boxes to the cloud, when our network latency assumptions got thrown out the window - but the bulk of those optimizations were simply "cache it".