OTP Performance

[Matthew Sackman]

Hi Joe,

Many thanks for your comments.

On Mon, Aug 21, 2006 at 11:50:44AM +0200, Joe Armstrong (TN/EAB) wrote:
> If you use cast in this way you need some proof that you won't overflow
> the message buffers.
> 
> If the producer is faster than the consumer then your program will
> eventually crash.
>
> By casting 10M message you probably are just filling the message queue,
> so
> what you have measured is the time to fill a queue,

Well yes, but if in both cases I don't start the receiver then they
should both take exactly the same time to send right? I've looked at the
code for gen_server:cast and it seems to, in the general case, end up
doing a erlang:send/2. So if in both cases it's just measuring the time
to fill a queue then why does the OTP version (with the
receiver/gen_server not started) take 35 seconds to send 10M messages
and the non-OTP version, sending to a dead Pid, take 0.5 seconds?

> you should really
> send a stop message. ie say flood(0, Target) -> Target ! stop.
> Then the stop time is the time when the receiver receives the stop
> message.
> Try this and report back :-)

Ok, I made the change, the performance is the same. And I have no idea
why sending the stop message before taking the second time measurement
would somehow make the receiver receive and process the stop message
before the sender completes the sending. Are there some semantics
attached to 'stop' atoms that I'm unaware of? I'm probably just confused
- lack of sleep and all that...

Surely the OTP version will always take much longer because of the use
of implicit apply?

If I did something like:

flood(0, Target) ->
    Target ! {stop, self()},
    receive
        End -> End
    end;

flood(N, Target) ->
    send(Target),
    flood(N-1, Target).

send(Target) ->
    Target ! ok.

receiver() ->
    receive
     {stop, From} ->
       From ! now(),
       exit(normal);
     _Else ->
       receiver()
    end.

Then it forces the stop to be synchronous. But I'm still getting 3.5
seconds for the non-OTP version. If I make a similar change to the OTP
version then I still get 17 seconds.

Many thanks for the rest of your comments - they all make sense to me.
:-)

Matthew
-- 
Matthew Sackman

BOFH excuse #336:
the xy axis in the trackball is coordinated with the summer solstice