From: Caleb Clausen <vikkous@...>
Date: 2010-05-14T07:11:50+09:00
Subject: Re: ease of porting (translating) ruby to C (vs. python)?

On 5/13/10, Charles Calvert <cbciv@yahoo.com> wrote:
> the horse.  Here is the correct order:
>
> 1. Write the code.
> 2. Test performance.
> 3. If performance is not acceptable, profile the code and identify the
> bottlenecks.
> 4. Examine the bottlenecks to see if the performance can be improved
> in the current language, e.g. by switching algorithms or tweaking
> generic algorithms to work better with your specific data.
> 5. Make those changes and retest.  You might need to experiment with a
> few versions.
> 6. If the changes result in insufficient improvement, then look at
> implementing them in C, compiling to a library and calling into that
> from Ruby/Python.

While one should not get overwrought about performance ahead of time,
it is something that should be considered at design time. I am not a
subscriber to the notion that many seem to promote that performance
should not be considered at all until you prove with benchmarks that
something is too slow. I don't need to run a bubble-sort to know that
it's slow.