IDE/Standalone Performance Issues - A Light At The End of the Tunnel!

[Richard Gaskin]

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