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
else
put the text of control ID myID into tdata
end if
else
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
themselves.
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
microsecond).
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
the IDE.
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. :)
--
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
