

Programming as if Performance Mattered (2004) - RiderOfGiraffes
http://dadgum.com/james/performance.html

======
srean
There is something I find interesting about online discussions around
performance issues (I am looking at you SO). The moment the question is asked,
people try to gang up and out-compete each other in providing the cookie-
cutter, patronizing, zero-information responses. Along the lines of (i) check
whether it is actually the bottleneck, (ii) use a better algorithm, (iii) dont
do it etc etc. Usually accompanied by (mis-attributed) quotes. Such advice
would typically be the highest voted.

What galls me is that they assume, without any basis, that the person has not
(a) benchmarked the code, (b) is obviously running an inferior algorithm and
(c) just because they have not worked on an applications were speed mattered,
the poster could not possibly be working on something where speed matters. If
I were the one who asked the question I would be mighty pissed, given that
just reading such comments as a third party irritates me enough.

The advice about premature optimization is valid. But it is a well assimilated
folklore by now and I dont see how repeating that adds value. I think Hoare
and Knuth's message was intended for a specific audience and the majority of
the online crowd is not that audience.This message is often interpreted by
enlightened newbies as an encouragement to be sloppy.

People would be better served if the discussion shifted to a different
landscape, where people pointed out that particular construct that was
typically more efficient among constructs of comparable clarity. Pointed out
possible bottlenecks ahead of time, so that it is on the developers mind and
he/she does not have to go through the process of coding a poor solution and
discovering that it sucks.

Also regardless of the fact whether the code construct is actually a
bottleneck in the application or not, it is always good to know what the more
efficient alternatives are. It might not be the bottleneck in the current
application, but it might well be in some other. Besides, there is something
called intellectual curiosity.

~~~
Tycho
The worst part is you can't tell them to fuck off because that would just be
'ungrateful.' They're only being patronising for _your own good!_

~~~
andos
Well, on SO you can always downvote the answer. It would be more effective if
it were the community norm to downvote the condescending answers, of course.
It's not the case, unfortunately.

~~~
Tycho
Condescending, presumptive no-info answers are often the top voted in my
experience.

~~~
back2dos
Well of course. If you say nothing, you can hardly be wrong :D

------
nickolai
Performance surely doensnt matter in the main stream - my grandma's computer
has comparable processing power to supercomputers 20 years ago( and she has a
Pentium 4, that has been obsoleted many times over already) [1]. But I think
google would pay attention to software performance on their Terabyte-eating
map-reduce clusters. Or someone who doesn't want their iphone app flagged as
"battery hog" for that matter.

"Pay attention", not as in squeeze out every extra cpu cycle they can, but as
in do the 10 % extra thinking that would get the reasonable 2-10 fold
improvement over the naive implementation. At least that's my experience -
maybe i'm just really bad with my naive implementations, YMMV.

[1][http://en.wikipedia.org/wiki/Orders_of_magnitude_%28computin...](http://en.wikipedia.org/wiki/Orders_of_magnitude_%28computing%29#109)

------
cyrus_
Ever wonder why your laptop fan turns on and you lose a half hour of battery
life when you load up a tiny, blocky online video? It can't be because the
video decoder is written in a language like Actionscript because everyone says
performance doesn't matter...

~~~
DarkShikari
Flash's video decoders are written in native code and pretty heavily assembly-
optimized. They're not as fast as they could be, but they're nothing compared
to something truly slow (e.g. reference decoders).

The high CPU usage is typically because of two things:

1) Flash has to do extra compositing to add ads and such onto video.

2) Flash typically doesn't use hardware acceleration for the actual blitting
-- their excuse is that on a significant % of computers, bad drivers will
result in crashes, and they'd rather be somewhat slow on 100% of computers
than crash 1% of them.

If you want something to complain about, go after the sites using Cortado to
decode video. Yet even that is still JIT'd, though completely lacking SIMD asm
due to being Java.

Disclaimer: I am not a developer of Flash, I just know one.

~~~
cyrus_
Thanks for the info -- but my point stands, performance is important when you
care about energy usage (mobile, laptop, server).

Really the only place its not important is GUI programming and high-level
application logic.

~~~
andos
Even GUI programmers need to be aware of performance. Painting can be
expensive, especially on mobile devices, and event handling must be swift or
else the app will feel unresponsive.

------
andos
I find it rather queer that, for the author, two data points are enough to
"put performance into proper perspective". Now that performance is gained from
scaling, it matters like never before.

~~~
wladimir
Well, you have to see this article from a pre-2004 perspective. Back then,
clock speeds were still increasing like crazy, like it'd never stop. This
luxury made people think things like "performance doesn't matter, processors
will get faster than we can optimize the code". The mindset that eventually
led to Vista.

We're wiser now. These days, performance can only be increased by adding more
cores, not by clocking up. Scaling up actually costs development effort. This
makes optimization very important.

See also this 2005 article from Dr Dobbs:
<http://www.gotw.ca/publications/concurrency-ddj.htm> . That's when the big
change of perspective began.

~~~
andos
You are right. I kept that in mind all along while reading the post, though I
perhaps showed less sympathy in my remark. I really regret if I sounded like a
smart-arse.

The link you posted is great; the chart alone speaks volumes! Already at that
point in time one could notice how the trend with power and CPU frequency was
changing, while transistor count kept on growing. James Hague would have had
second thoughts, I believe, if he had seen that chart. Moore's Law suffered
quite a plot twist the last decade.

(Curiously, Herb Sutter is the secretary of the C++ standards committee. They
finally finished the standardization of basic threading — among other stuff —
5 years after the Dr. Dobbs article!)

~~~
wladimir
Nah, I had the same reaction while reading the article. Then I realized that
it was from 2004.

The slow push for standardization is indeed curious. Standardizing threading
would only be the beginning, as threading is (for most things) a much too low-
level abstraction. It is very hard to scale threading, with the locking and
other synchronization it usually entails, to large number of cores (soon, >16
won't be that strange). And it's very bug-prone.

I think it's disappointing that more high-level primitives such as co-
routines, work queues, task-based parallelism, map/reduce and such are finding
such slow adaption in mainstream languages. You'd say that making the writing
of parallelized code faster and more robust is an important goal.

------
JoeAltmaier
I with the comparison with an efficient compiler was made. Not much to
conclude from the data given.

