17 Larry Wall Quotes on Performance

Larry Wall quotes on performance

9. If you want to program in C, program in C. It's a nice language. I use it occasionally... :-)

59. Doing linear scans over an associative array is like trying to club someone to death with a loaded Uzi.

111. It would be possible to optimize some forms of goto, but I haven't bothered.

113. How do Crays and Alphas handle the POSIX problem?

117. As someone pointed out, you could have an attribute that says 'optimize the heck out of this routine', and your definition of heck would be a parameter to the optimizer.

147. I was trying not to mention backtracking. Which, of course, means that yours is 'righter' than mine, in a theoretical sense.

156. Well, hey, let's just make everything into a closure, and then we'll have our general garbage collector, installed by 'use less memory'.

178. It's hard to tune heavily tuned code. :-)

181. Well, I think Perl should run faster than C. :-)

187. Perl should remain fast and intuitive (to the extent that it is :-)

199. Perhaps you should compile your Perl with long doubles one of these megaseconds.

246. str->str_pok |= SP_FBM; /* deep magic */ s = (unsigned char*)(str->str_ptr); /* deeper magic */

285. In computer science, it is said that premature optimization is the root of all evil.

296. I already have too much problem with people thinking the efficiency of a perl construct is related to its length. On the other hand, I'm perfectly capable of changing my mind next week... :-)

305. (Presuming for the sake of argument that it's even *possible* to design better code in Perl than in C. :-)

312. If ease of use was the highest goal, we'd all be driving golf carts.

315. Optimizations always bust things, because all optimizations are, in the long haul, a form of cheating, and cheaters eventually get caught.