Dispatch Versus Send

[Richard Gaskin]

Mark Wieder wrote:

> Richard-
>
> Thursday, March 4, 2010, 2:37:47 PM, you wrote:
>
>> FWIW, where they can be used interchangeably dispatch is about 20% faster.
>
> Have you benchmarked that?

You have to ask? :)

Here's a script I tested with back in September when I had to make some 
architectural decisions for an app with complex messaging:

on mouseUp
   put 100000 into n
   --
   -- Dispatch:
   put the millisecs into t
   repeat n
     dispatch "GetNada" to btn "b"
   end repeat
   put the millisecs - t into t1
   --
   -- Send:
   put the millisecs into t
   repeat n
     send "GetNada" to btn "b"
   end repeat
   put the millisecs - t into t2
   --
   put "Dispatch:  Total time: "&t1 &" ("& t1/n&" per iteration)"\
       &cr& "Send: : Total time: "&t2 &" ("& t2/n&" per iteration)"
end mouseUp


The GetNada handler is just a time-waster so we have a non-empty handler 
to call:

on GetNada
   get 1+1
end GetNada


Results:

Dispatch:  Total time: 250 (0.0025 per iteration)
Send: : Total time: 364 (0.00364 per iteration)


So it's actually much better than 20% faster (I must be getting old, my 
memory's going).

The per-iteration times are useful:  with either one we're talking about 
such a small fraction of a millisecond that it really won't
matter much when either is used occasionally.  When you need timers you 
shouldn't feel bad about losing 0.00114 milliseconds.  We had to burn 
through a hundred thousand iterations just to get to a quarter-second.

But if you don't need the timer delay, adopting dispatch as a habit can 
help save a few clock cycles here and there that you can spend on more 
useful things.  A lot of the stuff I'm working on is migrating to 
providing real-time updates to data views, so I take every convenient 
chance I can to save time to keep things snappy as we add new stuff.

Hats off to Mark Waddingham for the well-optimized implementation.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv