[erlang-questions] Erlang shows its slow face!

[Fred Hebert]

I think the first thing to do before optimizing is understanding how you use
the data. In the case of Pythagorean triplets like these, the right question
might as well be "how many triplets do I need? What values do I need to work
with?"

If 90% of your calls fall in the same range, you might as well just cache
the results and speed up 90% of the computations. No optimization required.
Then to reduce the overhead of the rest and maybe make the whole set of
queries more predictable, you could use Morgen's algorithm with a static or
a cached sieve table/incorporated primes for the edge cases, or allow the
algorithm to resume from the one you stored, etc.

There are many practical solutions that can require far less work than
rewriting the algorithm, making it harder to read. Understand the problem
before finding its solution.

On Mon, Nov 15, 2010 at 10:02 AM, Edmond Begumisa <
ebegumisa@REDACTED> wrote:

>
> I think of optimisation as something you put on a version 2 to-do list.
> Optimisation to me means staring hard at code and trying to figure out ways
> to get it to perform better (faster, less memory, less CPU time, etc). This
> normally means re-writing code that's easy to follow into code that's
> no-so-easy to follow. Mind you, for Erlang, I don't look at parallelising as
> optimisation as others seem to. To me, it's just a building block made
> available and normally it can be applied without changing an algo too much
> (I'd say it's not used enough).
>