IDE/Standalone Performance Issues - A Light At The End of the Tunnel!
ambassador at fourthworld.com
Thu Nov 11 16:03:07 CST 2010
Peter Haworth wrote:
> Here's a small example section of code which I've changed to use the
> ID where it used to use the long name. The variables are:
> myID holds the short ID of the control
> pselection a parameter passed into the command
> put the milliseconds into mymilliseconds
> writeDebug "Starting loadOneList" && the abbrev name of control ID myID
> if pselection is empty then
> if "listValues" is among the lines of the customKeys of control
> ID myID then
> put the listValues of control ID myID into tlistspec
> put the text of control ID myID into tdata
> end if
> put pselection into tlistspec
> end if
> if tlistspec is not empty then
> repeat for each line myLine in tlistspec
> writeDebug tab & (the milliseconds - mymilliseconds) & tab &
> "Start processing SELECT" && myline
What's interesting there is that the control is only being referenced
three times: once to write the debug string, a second time to check the
customKeys, and a third time to obtain the prop values.
Given that it's just three object references and most of the work is
done in the repeat look that works on the list, it's hard to believe
those three object references could account for the speed difference by
What does writeDebug look like, and what does the other half of the
repeat look like (there's no closing "end repeat")?
And what exactly is in myID? Have you verified that it's an integer,
and that the name was as you expected it in the earlier version?
Also, do you have any getProp handlers in your stack?
Perhaps most importantly: are there any other stacks or libraries used
by the standalone that aren't present in the IDE?
> It is puzzling why your tests don't reflect what Im experiencing.
Yeah, me too. :)
> Maybe it's something to do with the operation that is carried out on
> the control. In my case, most of the addressing of the controls
> consists of getting/setting their properties, both standard and
> custom. Could it have anything to do with the fact that my code is
> executed in a script that is held in a separate code library stack and
> inserted as a front script?
Possibly. It may be helpful to log the frontScripts, the backScripts,
and the stacksInUse in both the IDE and the standalone to see what
differences there may be. Of course you'll see a lot more of those in
the IDE, which should theoretically either have no effect or make it
slower, but perhaps a script is both in a library and a frontScript in
the standalone, causing it to execute more than once.
getProp and setProp handlers can be mystifyingly problematic because I
find that the more of those there are the more all custom property
accesses slow down (though the effect is very minor, a fraction of a
> The only other variable I can think of is
> the location of the debug log I'm writing to. In the IDE, the debug
> log is in the same folder as the stack file but in the standalone it's
> in the users Library/Preferences/<appname> folder. This is running on
> a Mac of course.
That's a noteworthy point. When diagnosing issues like this it's very
useful to eliminate differences between the working and non-working
implementations until you hone in on the root cause.
To verify that this isn't an issue with writing to a different location,
you might consider altering the standalone (at least temporarily, for
this test) so that it writes to the same location as when it's run in
> All I have to do now is find all the places in my code where controls
> are referenced by their long name - oh joy!
Hopefully we'll be able to find a different root cause than the current
apparent one, maybe one that requires less work to remedy. :)
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
More information about the use-livecode