SWAP

[FourthWorld]

Excellent work, ukimiku. Thanks for taking the time to do that.

I'd guess that command is faster than on because of how they get handled in the message path lookup table. It's interesting that command is so much faster. Certainly worth updating one's habits for, and also raises expectations for how other parts of the engine may be optimized over time.

[mwieder]

I learned something here, too. I had no idea that "command" would be faster than "on" - I just assumed they were synonyms in the engine. Never bothered benchmarking it. Thanks for doing the legwork. Now I'm off to change a bunch of code...

[bn]

I get from this discussion that command and on behave differently. I is of note that in ukimikus code the on handler was a different handler then the command handler. Comparing command and on with the same algorithm they are equivalent with regards to speed. Only private is faster. I tested with 'loaded' variables and got private: 1665 command: 2359 on: 2371, this differs slightly from test to test but is consistent overall. I tested with this code:

Code: Select all

on mouseUp
  -- Many tasks are so quick they don't show a measurable
  -- difference unless they're run multiple times, so we
      -- run through the number of iterations specified here:
      put 123456789 into tA
      put 987654321 into tB
  put 1000000 into tIterations
  --
  -- TEST 1:
  put the millisecs into t
  repeat tIterations
  swapA tA, tB
  end repeat
  put the millisecs - t into t1
  --
  -- TEST 2:
  put the millisecs into t
  repeat tIterations
  swapB tA, tB
  end repeat
  put the millisecs - t into t2
  
    -- TEST 3:
  put the millisecs into t
  repeat tIterations
     swapD tA, tB
  end repeat
  put the millisecs - t into t3
  
--
-- DISPLAY RESULTS:
  put "private: " & t1 & " command: " & t2  & " on: " & t3
end mouseUp

private command swapA @pA, @pB
  get pA
  put pB into pA
  put it into pB
end swapA

command swapB @pA, @pB
  get pA
  put pB into pA
  put it into pB
end swapB

on swapD @pA, @pB
  get pA
  put pB into pA
  put it into pB
end swapD

please check this out before rewriting your code...
regards
Bernd

[ukimiku]

Hi Bernd,

you're right. Don't know how that slip could happen.
Anyhow, "private", where applicable, seems to guarantee significantly higher execution speed.

Regards,

[mwieder]

Ah... good catch.

[FourthWorld]

I get from this discussion that command and on behave differently. I is of note that in ukimikus code the on handler was a different handler then the command handler. Comparing command and on with the same algorithm they are equivalent with regards to speed. Only private is faster.

Good sleuthing, Bernd. This is consistent with my previous understanding, since "on" and "command" are allowable as synonymous currently, so it seems reasonable that they would go through the same process in terms of how they're handled by the engine.

That "private" would be faster is understandable, since it isn't available to any other handlers so it doesn't go into the same longer message path as other handlers.

[malte]

Did anyone do a speed test on how behaviors would fit in the list?

Cheers,

Malte

[FourthWorld]

I did some benchmarking with behaviors when v3.5 first came out, and was impressed with the speed boost.

I did a variety of tests and would have to dig into my drive to find them all, but the results were very favorable compared with equivalent alternatives like using "send" or using a library that differentiates by checking a custom property in the target. IIRC behaviors were more than twice as fast than using "send" (no big surprise there, since "send" is notoriously slow), and more than 30-40% faster than differentiating by property (again not too surprising given the extra steps involved with that and the leanness of having behaviors only in the message space for the objects they're assigned to).

[malte]

Thanks Richard. It does indeed not surprise me much, but it is good to know that the gut feeling does not deceive me.

Cheers,

malte