# End-to-End performance - premature optimization **URL:** \ **Category:** Ruby\ **Created:** [August 8, 2006, 7:30pm UTC](https://www.ruby-forum.com/t/end-to-end-performance-premature-optimization/101938 "2006-08-08T19:30:23Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![igouy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/ce7236/32.png) [@igouy](https://www.ruby-forum.com/u/igouy)\ **Post date:** [August 8, 2006, 7:30pm UTC](https://www.ruby-forum.com/t/end-to-end-performance-premature-optimization/101938/1 "2006-08-08T19:30:23Z")
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.