Another small objection that I just remembered, Casey has an interview with Rico Mariani[1] who worked on performance at Microsoft for two decades, from their first C++ compiler, to .NET, to web browsers.
He coined the phrase "pit of success" after his team had spent months profiling and tuning the .NET startup to remove many milliseconds from it. One developer on another team called a default constructor for an XML class, and in that commit wiped out all their gains, three times over, he didn't know the default path was slow and there was another way. Rico was giving a talk and said that isn't a good way to design things, success can't be the hard way that only a few experts can find, it has to be like 'falling into a pit', the default way to do things has to be the good way.
Anyway, with one browser related performance regression, they profiled and found that the layout engine was using a lot more CPU. He believed the layout engine was good enough, looked elsewhere and found a commit which invalidated a node in a tree and all subnodes. That was cheap and didn't stand out in the trace, but far away in the codebase it triggered a lot of layout updates. Separating things out to focus on just one part at a time, and then the profiler can reveal where the problems are, neither of those things worked as intended.
He coined the phrase "pit of success" after his team had spent months profiling and tuning the .NET startup to remove many milliseconds from it. One developer on another team called a default constructor for an XML class, and in that commit wiped out all their gains, three times over, he didn't know the default path was slow and there was another way. Rico was giving a talk and said that isn't a good way to design things, success can't be the hard way that only a few experts can find, it has to be like 'falling into a pit', the default way to do things has to be the good way.
Anyway, with one browser related performance regression, they profiled and found that the layout engine was using a lot more CPU. He believed the layout engine was good enough, looked elsewhere and found a commit which invalidated a node in a tree and all subnodes. That was cheap and didn't stand out in the trace, but far away in the codebase it triggered a lot of layout updates. Separating things out to focus on just one part at a time, and then the profiler can reveal where the problems are, neither of those things worked as intended.
[1] https://www.youtube.com/watch?v=48Rig6v-xYU