Performance Mystery Solved - IT'S THE DATA STUPID!!
ambassador at fourthworld.com
Fri Nov 12 08:27:03 CST 2010
Peter Haworth wrote:
> I have to admit you guys left me behind a while ago. But I'm glad I
> may have created a platform for some knowledge that wasn't there
> before, plus I've got a fix for my problem so yes, definitely a good
Thanks again for not only bringing this up, but for diligently working
it through to find the root cause. Good work.
After thinking about it some more, I think I understand why the speed
The various tests I ran showed that there is some overhead in resolving
file paths to stack files vs. simply using the short name of the stack.
While this difference is trivial when accessing just the stack itself,
it becomes amplified when walking through each of the controls in the stack.
Comparing Monte's results using 500 controls with a simpler stack with
only 10 controls, the difference in the timing seems somewhat linear in
relation to the number of controls being traversed.
So in short, it seems that it's not so much a problem with using paths
to access controls, but the number of times that's done. The more times
you ask the engine to resolve a path, the more that will affect speed.
I guess that's kinda obvious, but at first I had thought the issue was
that control references were somehow taking longer than stack
references, which would be even more mystifying.
This has been a very useful exploration. While it's not often that I
write routines that walk through all controls in a stack, when I do I
now understand that opening the stack invisibly first will greatly
Monte, thanks again for your test. Most illuminating.
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog:
More information about the use-livecode