

Writing Efficient Programs (1990) - dedalus
http://www.crowl.org/lawrence/programming/Bentley82.html

======
TickleSteve
All these still apply equally well today, but most have forgotten about them.

If you want to any form of performance or efficiency, you still need to pay
attention to these.

------
nine_k
Read this text from 1982 (33 years ago) and wonder at the great lengths one
had to go to write efficient programs at the age of scarce computational
resources and simplistic compilers.

~~~
barrkel
Sometimes you need to go further today, due to the complex and capricious
compilers.

Not so long ago, I had to write a piece of Java code that sniffed a text file
and tried to guess its encoding. The submitted files could be over a gigabyte
in size - speed was a concern. We decided to support three main cases: pure
ASCII, UTF8, and final fall-back to Windows-1252 in case of invalid UTF8
sequences. The idea being that the most common non-UTF8 file we'd have to
support came from Western European Windows machines, and customers could
always convert to UTF8 in case of encoding problems.

Writing the Java loop for scanning over the bytes, testing for high bits and
UTF8 sequences, was interesting. Manual loop unrolling was a win when the loop
body was complex, but an even bigger win was making the loop body extremely
simple and making it break out whenever a high bit was seen; in this case,
Hotspot did the unrolling itself. The simpler the code, the more reliably the
JVM could unroll and hoist array bounds checking out. The final code walked a
tightrope between getting more work with fewer branches, and less work so that
Hotspot could optimize. Try to do a tiny bit too much, and performance fell
off a cliff.

Looking at the generated assembly was still worthwhile to get an estimate of
how much performance the JVM was leaving on the table, and whether or not it
was worth working harder to extract it.

------
Narishma
The article is from 1990, but the book it is summarizing is from 1982.

