End-to-End performance - premature optimization

Peter H. wrote:

Isaac G. 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 B. 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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs