gen_fsm:send_after | start_timer

Ulf Wiger etxuwig@REDACTED
Wed Jul 11 14:41:23 CEST 2001


On Tue, 10 Jul 2001, Sean Hinde wrote:

>> An erlang implementation simply cannot compete with the built-in
>> timeout support, and apply_after should basically only do the
>> required extra of spawning a process to give the function an
>> execution context. Everything else is just garnish.
>
>What about the performance difference between your apply_after and
>erlang:start_timer?

It's somewhere in the neighbourhood of 5x more overhead:
erlang:start_timer/3 clocks in at about 20-25 us. Spawning a
process costs a bit more. Our apply_after was less than 100 us
overhead last time I checked (which was a while ago on a
36MHz SuperSPARC.)

>Do you know if receive loops use the same timer wheel?

Yes, they do.


>How about:
>
>apply_after(T, M, F, A) ->
>	erlang:start_timer(T, timer, {apply, M, F, A}).
>
>%% Permanent loop registered as {local, timer}:
>
>loop() ->
>    receive
>        {timeout, Ref, {apply, M, F, A}} ->
>            spawn_link(?MODULE, do, [M, F, A, self()]),
>            loop().
>
>do(M, F, A, Pid) ->
>	apply(M, F, A).
>	unlink(Pid).

You will reduce the overhead, but add latency since all the
timer functions must be serialized. This will force the
requirement on the user of the timer to keep the function very
short, which is sometimes inconvenient.

Also, I'd put a catch around the apply. ;)


>This avoids having lots of extra processes lying around (but the timer isn't
>linked to the requesting process).

Yes, but Erlang handles lots of extra processes exceedingly well.
I wouldn't worry about the performance aspect, but memory could
sometimes be a factor.

/Uffe
-- 
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB




More information about the erlang-questions mailing list