From: Tim Bray <tbray@...>
Date: 2006-07-28T08:11:17+09:00
Subject: Re: For performance, write it in C

Sorry for coming late to the party.

On Jul 26, 2006, at 1:47 AM, Peter Hickman wrote:

> Whenever the question of performance comes up with scripting  
> languages such as Ruby, Perl or Python there will be people whose  
> response can be summarised as "Write it in C".

The conclusion is wrong in the general case.  Suppose that, instead  
of computing permutations, your task had been to read ten million  
lines of textual log files and track statistics about certain kinds  
of events coded in there.  I bet a version coded in perl, making  
straightforward uses of regexes and hashes, would have performance  
that would be very hard to match in C or any other language.  Ruby  
would be a little slower I bet just because Perl's regex engine is so  
highly-tuned, although it's been claimed Oniguruma is faster.

So, first gripe: C is faster than Ruby *in certain problem domains*.   
In others, it's not.

Second gripe.  The notion of doing a wholesale rewrite in C is almost  
certainly wrong.  In fact, the notion of doing any kind of serious  
hacking, without doing some measuring first, is almost always wrong.   
The *right* way to build software that performs well is to write a  
natural, idiomatic implementation, trying to avoid stupid design  
errors but not worrying too much about performance.  If it's fast  
enough, you're done.  If it's not fast enough, don't write another  
line of code till you've used used a profiler and understand what the  
problem is.  If in fact this is the kind of a problem where C is  
going to do better, chances are you only have to replace 10% of your  
code to get 90% of the available speedup.

And don't remember to budget downstream maintenance time for the  
memory-allocation errors and libc dependencies and so on that cause C  
programs to be subject to periodic downstream crashes.

  -Tim