[erlang-questions] Coming Back (maybe improving lists:reverse/1)

[Ivan Carmenates Garcia]

Yes that is so, but in my case, I cannot find a better way to improve it, I
did it as better could so, that's when Joes words give me pleasure. ;)

Regards,
Ivan (son of Gilberio).


-----Original Message-----
From: Richard A. O'Keefe [mailto:ok@REDACTED] 
Sent: Wednesday, October 7, 2015 7:51 PM
To: Ivan Carmenates Garcia
Cc: Erik Søe Sørensen; Erlang Questions Mailing List
Subject: Re: [erlang-questions] Coming Back (maybe improving
lists:reverse/1)


On 8/10/2015, at 11:49 am, Ivan Carmenates Garcia <co7eb@REDACTED>
wrote:

> Nice.
>  
> So in order of balance between memory and speed is the best ways as it
is?.

Ill-posed qwuestion.  No answer is possible until you specify best in *what
respect* for *what purpose*.

Doubly linked lists are said to have their uses, but any time I've been
tempted to use them, some other data structure has always turned out to be
much better.  There are actually several different ways to implement singly
linked lists (anyone else out there remember CDR-coding?) more than one of
which could be used for Erlang, so it's even harder to assign any meaning to
the question than you might think.

For example, I have a library that I've ported to several functional
programming languages providing unrolled lists.  For example,

    data URSL t
       = Cons4 t t t t (URSL t)
       | End3 t t t
       | End2 t t 
       | End1 t
       | End0

This takes 6 words for every 4 elements, an average of 1.5 words per
element.  (A doubly linked list would require at least twice as much.) On
the other hand, it's very bad at prepending a single element.  So unroll
from the _other_ end; that way you need one End but more than one Cons.  

> Okay, sounds good to me, also Joe was saying something that I like some
kind about algorithms optimizations, because I am a little bit hard about
it, but for example in this little framework I am doing for myself and the
community if they like of course there are parts in which maybe I think some
algorithms could be better but if it works and it does quite well, i.e. if
in my computer with one millions of iterations in one process this is
important because each user will have one process for its own, it take 21
seconds to perform and in a core i3 with 2 GB of single channel memory it
take 9 seconds, then in a real server with 64 cores and super memory it will
take none milliseconds to perform so, in the future machines will be better
each time and maybe we don’t have to be so extreme about performance.

This is extremely vague.  All I can say is

    Remember that the BIGGEST performance gains come
    from optimising at the HIGHEST level.