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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
