<div dir="ltr">"<span style="font-size:12.8px">Choosing a smart algorithm that is </span><span style="font-size:12.8px">intrinsically efficient is not something that I consider to be an </span><span style="font-size:12.8px">optimisation </span><span style="font-size:12.8px">but rather good design." -Joe<br></span><br>This can not be pointed out enough. A significant number of slow systems in my experience are due to authors not properly understanding or recognizing the costs, in memory and cpu, of the functions and data structures they use. My example was less about speed and more about understanding that 2 * O(n) on an unbounded list is dangerous and there are reasonably simple ways to handle the situation that are arguably easier to read, clearly faster, and have upperbounds on costs. That original function should hopefully stick out as a possibly dangerous and costly design in almost an instinctive way.<div><br></div><div>To take my paranoia regarding such things further... in a situation like this, depending on the source of the data, it may be better to not use lists. Maybe tuples. Or carry the length around separately if originally stored in a way where it was already calculated. And it's not just for speed but not throwing away information unnecessarily. Not making assumptions about how the data will be used such that getting that information back later could be costly. In this case it's very similar to char* strings in C. Often the length is known at some point but almost always thrown away leading to many functions needing to recalculate it.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 20, 2016 at 4:34 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Sep 20, 2016 at 9:55 PM, Jesper Louis Andersen<br>
<<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.<wbr>com</a>> wrote:<br>
><br>
> On Tue, Sep 20, 2016 at 6:52 PM, Lloyd R. Prentice <<a href="mailto:lloyd@writersglen.com">lloyd@writersglen.com</a>><br>
> wrote:<br>
>><br>
>> Question: how can we time the proposed solutions to compare performance?<br>
><br>
><br>
> One solution is <a href="https://github.com/jlouis/eministat" rel="noreferrer" target="_blank">https://github.com/jlouis/<wbr>eministat</a><br>
><br>
> But one has to weigh the most efficient solution against two things:<br>
><br>
> * Which solution is the most readable and elegant. It is more likely to be<br>
> correct.<br>
> * How many ISBN numbers per second are we looking at?<br>
><br>
> Modern computers are unfairly quick at computation once data are on the CPU<br>
> itself. So unless you have a very large count of ISBN numbers to verify, I<br>
> would perhaps spend my time elsewhere in the code base. Your systems overall<br>
> efficiency is likely to suffer from other factors than a single ISBN<br>
> verification.<br>
<br>
</span>Agreed - if you think about it, the ISBN number must have come from<br>
*somewhere* - if they have come from disk then at a guess<br>
most of the time will be spent reading and parsing the input. If they come<br>
from a database most of the time will be in format conversions.<br>
<br>
Once the ISBN is in RAM then any processing involved will be fast.<br>
Modern processors do Giga instructions/second so converting<br>
millions of ISBN/second should not be a problem - reading and *parsing*<br>
millions of numbers per second would be a problem)<br>
<br>
The 'old truth' was that most time in most applications was spent in I/O<br>
not in computation (apart from computational heavy problems)<br>
<br>
The problem with comparing different versions of the routine<br>
isbn_format_valid that you don't see the big picture. If isbn_format_valid<br>
only takes 1% if the total time then it doesn't matter if you<br>
optimize it.<br>
<br>
The old advice was write as clearly as possible, measure, then<br>
optimize the least efficient part *if necessary*.<br>
<br>
In my experience optimization is hardly ever needed - of all the code I've<br>
ever written only a tiny fraction ever really needed optimizing.<br>
<br>
By optimization I mean choosing complex code that is fast, rather than simple<br>
code that is easy to understand. Choosing a smart algorithm that is<br>
intrinsically efficient is not something that I consider to be an<br>
optimisation<br>
but rather good design.<br>
<br>
The advice - "write first - then measure" is difficult to follow since<br>
measurements are difficult to make and interpret. The only thing I<br>
know is<br>
that my intuition as to where the time really goes is almost always<br>
wrong (apart from in I/O which is always slow)<br>
<br>
/Joe<br>
<br>
><br>
><br>
> --<br>
> J.<br>
><br>
> ______________________________<wbr>_________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
><br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</blockquote></div><br></div>