[_ah]

Wow, this takes me back.

I actually worked on Office performance many years ago. We did a lot of very clever stuff to improve the product, even to the point of optimizing the byte ordering on disk (spinning rust) so that the initial boot would be faster.

That said, it always felt a bit like a losing battle. The goal was "make Office not get slower". It's very hard to convince app teams that their new shiny abstraction or graphics object is actually the reason everything is worse, and it's even more challenging when there's no direct impact- just a broad increase in system memory pressure.

Typically, perf isn't a few bad decisions. It's a very large number of independently reasonable decisions that add up to a bad result. If the team loses that discipline for even one moment then it's very very difficult to fix. I wonder if my former team still exists or if they've all been reassigned elsewhere.

[pradn]

> Typically, perf isn't a few bad decisions. It's a very large number of independently reasonable decisions that add up to a bad result. If the team loses that discipline for even one moment then it's very very difficult to fix. I wonder if my former team still exists or if they've all been reassigned elsewhere.

This is precisely where the adage "premature optimization is the root of all evil" falls apart. You really do need everyone to care about performance to an obsessive, unreasonable degree to keep the entire, massive system performant. Companies with good engineering leadership understand this. The thousand cuts can come from language, libraries, feature creep, and pure ignorance or carelessness.

[navane]

It's not premature if your crafting an office product in 2025 which sits in a direct line of 30 years of the same word processor.

[pradn]

It's premature in the sense that you need to care about it before you do profiling, which is the usual advice for perf improvements: "you don't know where the hotspots are, so write your code, profile it, and fix the slow bits".

[nikanj]

And if you try to bring up perf at any point during the design phase, people pull the ”Knuth said premature optimization is the root of all evil” card. As if you could design and build a Ford Pinto, then hotspot optimize it into a Saturn V

[godelski]

  > people pull the ”Knuth said premature optimization is the root of all evil” card.

Incredible how so many people misuse quotes and end up undermining the the whole point of the quote.

So for everyone that doesn't understand, here's the longer quote

  There is no doubt that the holy grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

  Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.

Knuth said: "Get a profiler and make sure that you're optimizing the right thing"

It is incredible how this became "don't optimize".

  https://dl.acm.org/doi/10.1145/356635.356640
  (alt) https://sci-hub.se/10.1145/356635.356640

[majkinetor]

I guess he was thinking that u might not need Saturn V. If u later decide based on more info that u need it, drop the old work and make perfy version from 0. I yhink that is reasonable given how much more work and resources it requires

[calf]

Was Knuth talking about deployed software when he wrote that?

[nikanj]

He wrote that in 1974. Software products were orders of magnitude smaller back then.