Performance Mystery Solved - IT'S THE DATA STUPID!!

[Richard Gaskin]

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
> day!

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 
difference happens:

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 
improve performance.

Monte, thanks again for your test.  Most illuminating.

--
  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.irvssador@FourthWorld.com 
http://www.FourthWorld.com