IDE/Standalone Performance Issues - A Light At The End of the Tunnel!

[Richard Gaskin]

Peter Haworth wrote:

> I think I have found  the cause of the performance problems I have
> been experiencing.  I had been referring to objects by their long name
> in various places in the offending code.  I started changing the code
> to refer to the same objects by their short ID and each line of code I
> changed resulted in quicker performance.  I haven't been able to
> change all the code yet but the evidence is that the performance
> issues will go away when I start using the object IDs everywhere.

Interesting.  I just ran this test:

on mouseUp
   put 100000 into n
   --
   put the millisecs into t
   repeat n
     put the short id of this cd into tID
     put the name of cd id tID into r1
   end repeat
   put the millisecs - t into t1
   --
   put the millisecs into t
   repeat n
     put the long name of this cd into tName
     put the name of tName into r2
   end repeat
   put the millisecs - t into t2
   --
   put the millisecs into t
   repeat n
     put the number of this cd into tNum
     put the name of cd tNum into r3
   end repeat
   put the millisecs - t into t3
   --
   put t1 && t2 && t3 && (r1=r3)
end mouseUp


The results were roughly the same in both the MC and Rev IDEs:

221 954 209 true

So addressing by ordinal number is slightly faster than by ID, which has 
been the case since the HC days.  But I'm surprised by how much faster 
both are compared to addressing by name.

This got me curious as to whether long ID would be faster than long 
name, so I ran this:

on mouseUp
   put 100000 into n
   --
   put the millisecs into t
   repeat n
     put the long id of this cd into tID
     put the name of tID into r1
   end repeat
   put the millisecs - t into t1
   --
   put the millisecs into t
   repeat n
     put the long name of this cd into tName
     put the name of tName into r2
   end repeat
   put the millisecs - t into t2
   --
   put t1 && t2 && (r1=r2)
end mouseUp


...and got this:

955 957 true

So it seems that the overhead of resolving absolute object references 
(long form) is much higher than what the engine can do when you're able 
to hard-wire part of the reference (e.g., "...of card id tID...").

Historically I've often used long IDs for the convenience of having an 
absolute object reference without regard to the type, but after seeing 
these results I can see that there's a benefit to hard-wire the type in 
script where practical.

Thanks for bringing this up.  Learn sumpin' new every day. :)


> Finding the problem is good of course but does anyone know why there
> are no performance issues referring to an object by it's long name in
> the IDE but it causes such a performance hit in a standalone?

Interesting as it was to test the different ways to reference objects, 
in practical terms I think the performance issue you encountered is due 
to something else.

The tests shown above were run in 100,000 iterations.  So while it seems 
impressive that one took only 25% as much time as another, in a given 
iteration the longest one took only 0.00954 ms.

Unless you're addressing several hundred thousand objects at a time, 
it's hard to imagine how the difference could product a noticeable effect.

I even built a standalone of the test stack, and while it was somewhat 
slower (why would that be?) the difference between the IDE and the 
standalone was less than 8% total, or about 0.0008 ms per call.

This is disappointing because it leaves the mystery unresolved, unless I 
misunderstand something here.

Can you post the section of code in question so we can see what else 
might be at play?

Also, have you compared timing tests of an isolated portion of the code 
to hone in on where the performance is lost?

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv