3 ms·
> I reran the benchmarks. I had removed 50% of calls to a function that took 10% of our time, and the code overall was now 20% (twenty percent!) faster. This r
by johnmaguire2013 11y ago
> I reran the benchmarks. I had removed 50% of calls to a function that took 10% of our time, and the code overall was now 20% (twenty percent!) faster.
This reminds me on another comment I read on HN, that I consider something of a "performance paradox": https://news.ycombinator.com/item?id=9895531 https://news.ycombinator.com/item?id=9895531
- hinkley 11y agoIn this case I only made one change and remeasured. Runtime dropped more than the cumulative call time of that function. But the thread you reference is a whole other kettle of fish, and I would call that observation #3 about failing at math. Your boss says the app needs to run 3x as fast. Not "try to make it 3x faster" but "the customer isn't going to buy unless it's 3x faster because competitors". With targets like that anything taking more than 3% of run time is a target for improvement, because they are taking 10% of the goal run time. People will adamantly refuse to look at the 4th slowest function until they've done something brilliant with the others, even if it's the easiest to fix. That function is only taking 10% of the time, they'll say, so it's not important. But it's taking 30% of the goal run time, and that's huge.
- steveklabnik 11y agoSometimes, I think Amdahl's Law is the most useful thing I learned about during my CS degree.