From: Isaac Gouy <igouy@...>
Date: 2006-08-09T02:30:05+09:00
Subject: End-to-End performance - premature optimization


Peter Hickman wrote:
> Isaac Gouy wrote:
-snip-
> > D and Clean are other languages you might look at, but using a
> > different language won't make what you're trying to do any more
> > feasible.
> >
> True, but as I've said before C is a fragile language to work in if
> you've come from a scripting background. A program will compile and then
> crash with not the slightest hint at what went wrong, so any language
> that will allow me to get that sort of performance with a better support
> is a good thing. I will be learning Ocaml for this reason alone.

OCaml is a fine programming language... (and so are Haskell, Ruby,
....)

Tim Bray mentioned the conventional wisdom about premature
optimization, let's be a bit more specific about why bothering about
programming language is a premature optimization in this particular
case.

We've started bothering about how fast the first stage of your
application performs, without knowing anything about the performance of
the rest of the application - that's premature.

Before we start bothering about application performance we need an
end-to-end application, so we can see which parts of the application
are limiting overall performance. There's no point trying to speed-up
generation of latin squares if the application performance is limited
by something else.

Using Perl or Ruby to generate latin squares could be just fine, as
long as they do it faster than the next stage of the application
consumes latin squares.