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

Richard A. O'Keefe <>
Thu Oct 8 01:51:07 CEST 2015


On 8/10/2015, at 11:49 am, Ivan Carmenates Garcia <> 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.



More information about the erlang-questions mailing list