[notzorbo3]

Managers often think throwing more hardware at the problem will fix things. But hardware scales sub-linearly. Solving the actual underlying problems can easily get you exponential payoffs.

Anecdote: One of my managers once spent €70000¹ worth of hardware to speed up an application because he believed it would be cheaper than to optimize the code. Naturally, no-one had done any kind of performance analysis, so while the upgrade made things about 20% faster, it still wasn't enough. It took me all of 20 minutes to figure out that caching was disabled on the database and it had no indexes whatsoever². 30 minutes of work yielded a few thousand percent speed increase.

¹) This was a long time ago before SSDs existed and buying a hardware RAID of fast disks and fast CPUs / memory was extremely expensive.

²) DBAer consultants of a certain large database vendor are not worth the horrendous hourly fee they ask.

[peteretep]

    > Managers often think throwing more
    > hardware at the problem will fix things

It often will...

    > no-one had done any kind of performance
    > analysis

... is the moral of this story

[nur0n]

I think we agree on the basic point: you can't decide what the most cost effective solution is until analysis is carried out. But an effective performance analysis can't be executed without an understanding of the machine.

Lacking low level knowledge can only create blind spots in the analysis.

[chillingeffect]

Nice work! This is where legends of 10x programmers come from.... they're 2x programmers in a world of 0.2x programmers ;)

[laydn]

That almost physically hurts to read!

The performance modelling teams working for the large CPU makers get several code traces from major database vendors to optimize the execution of critical pieces of database code. They do a cycle-by-cycle analysis.

And then people run the databases with caching and indexing disabled. Go figure