[erlang-questions] generators/iterators

[Joe Armstrong]

Setting up a function call is faster that a message send and receive - I guess
the main difference will show up in the concurrency. Doing things in
the same process with
a function call means the code will always be sequential. Using a
send/receive and
an additional process increases the concurrency - which is beneficial
if you have a
multicore. Erlang processes are very lightweight and you can create
*lots* of them
- a typical beginners error is "not to use enough processes" because you somehow
imagine them to be expensive ... The best advice is to forget about
efficiency and program
in the most beautiful way possible - using processes to model the real
concurrent structure in your problem - if this is not fast enough -
then measure and optimise as necessary.

/Joe


On 6/18/07, Damien Morton <dmorton@REDACTED> wrote:
> Im new to Erlang - so its just that - a guess. But ... when I imagine
> what the machinery for a message send is, compared to what I know the
> machinery for a function call is, at last in broad strokes, if a fun
> call isnt faster, it should be.
>
> The speed is one thing - but I think the more important reason is that
> the fun call subsumes the message receive, that is, the
> generator-as-repeated-fun call can implement receive functionality
> easily if desired, but it would tend to be awkward to do it the other
> way around.
> >> I guess calling a fun is much faster than sending messages between
> >> processes.
> >>
> >
> > Well that'd certainly be a good reason. I don't know that I've seen the
> > numbers. I have seen stuff that suggests calling a fun is a bunch slower
> > than calling a defined module-member function.
> >
> >
> > --
> > [ I love pre-moistened towelettes ] Mike McNally -- m5@REDACTED
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
> >
> >
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>