“Sometimes, in the development of the browser, even our best investigations and “thinking outside the box” ideas weren’t sufficient. There were plenty of instances when we were about to integrate a new feature, only to find that there truly was no way to add the code without a negative impact on speed. As we introduced features like clicking the back button to return you to your previously viewed web page, we found we couldn’t perform the bookkeeping to maintain the previous page at quick readiness without impeding the load of all pages. The PLT showed the slowdown. When we deemed such features too important to skip but couldn’t figure out how to add them without causing such slowdowns, we instituted a trading scheme, where we found speedups in unrelated parts of our existing source code to “pay for” the performance cost of the new features. When we looked around for code to perform this kind of payoff optimization, we typically targeted code we knew well and that was stable, preferably both. Once found, we tuned this proxy code to function the same, only faster, and sufficiently faster that we wound up with either a nil or a positive net impact on performance when we added both the feature-laden code and the speed-payoff code to our project.”