[erlang-questions] List comprehension puzzler

[Joe Armstrong]

On Tue, Sep 20, 2016 at 9:55 PM, Jesper Louis Andersen
<jesper.louis.andersen@REDACTED> wrote:
>
> On Tue, Sep 20, 2016 at 6:52 PM, Lloyd R. Prentice <lloyd@REDACTED>
> wrote:
>>
>> Question: how can we time the proposed solutions to compare performance?
>
>
> One solution is https://github.com/jlouis/eministat
>
> But one has to weigh the most efficient solution against two things:
>
> * Which solution is the most readable and elegant. It is more likely to be
> correct.
> * How many ISBN numbers per second are we looking at?
>
> Modern computers are unfairly quick at computation once data are on the CPU
> itself. So unless you have a very large count of ISBN numbers to verify, I
> would perhaps spend my time elsewhere in the code base. Your systems overall
> efficiency is likely to suffer from other factors than a single ISBN
> verification.

Agreed - if you think about it, the ISBN number must have come from
*somewhere* - if they have come from disk then at a guess
most of the time will be spent reading and parsing the input. If they come
from a database most of the time will be in format conversions.

Once the ISBN is in RAM then any processing involved will be fast.
Modern processors do Giga instructions/second so converting
millions of ISBN/second should not be a problem - reading and *parsing*
millions of numbers per second would be a problem)

The 'old truth' was that most time in most applications was spent in I/O
not in computation (apart from computational heavy problems)

The problem with comparing different versions of the routine
isbn_format_valid that you don't see the big picture. If isbn_format_valid
only takes 1% if the total time then it doesn't matter if you
optimize it.

The old advice was write as clearly as possible, measure, then
optimize the least efficient part *if necessary*.

In my experience optimization is hardly ever needed - of all the code I've
ever written only a tiny fraction ever really needed optimizing.

By optimization I mean choosing complex code that is fast, rather than simple
code that is easy to understand. Choosing a smart algorithm that is
intrinsically efficient is not something that I consider to be an
optimisation
but rather good design.

The advice - "write first - then measure" is difficult to follow since
measurements are difficult to make and interpret. The only thing I
know is
that my intuition as to where the time really goes is almost always
wrong (apart from in I/O which is always slow)

/Joe

>
>
> --
> J.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>