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

Peter Haworth pete at mollysrevenge.com
Thu Nov 11 16:38:35 EST 2010


Thanks for delving into this Richard.

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

In the IDE, the 2nd writeDebug shows a value of 1 whether I use the  
long name or the ID of the control.  In the standalone, using the long  
name it shows a value of 731 and using the ID it shows 1 again.

It is puzzling why your tests don't reflect what Im experiencing.  
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?  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.

All I have to do now is find all the places in my code where controls  
are referenced by their long name - oh joy!

Bob - I want to hold off just a little longer before submitting a  
bug.  The fact that Richard's tests don;t reflect what I'm seeing make  
me nervous that it's something I'm doing wrong!

Pete

On Nov 11, 2010, at 11:04 AM, Richard Gaskin wrote:

>
> Interesting.  I just ran this test:
>
> on mouseUp
>  put 100000 into n
>  --
>  put the millisecs into t
>  repeat n
>    put the short id of this cd into tID
>    put the name of cd id tID into r1
>  end repeat
>  put the millisecs - t into t1
>  --
>  put the millisecs into t
>  repeat n
>    put the long name of this cd into tName
>    put the name of tName into r2
>  end repeat
>  put the millisecs - t into t2
>  --
>  put the millisecs into t
>  repeat n
>    put the number of this cd into tNum
>    put the name of cd tNum into r3
>  end repeat
>  put the millisecs - t into t3
>  --
>  put t1 && t2 && t3 && (r1=r3)
> end mouseUp
>
>
> The results were roughly the same in both the MC and Rev IDEs:
>
> 221 954 209 true
>
> So addressing by ordinal number is slightly faster than by ID, which  
> has been the case since the HC days.  But I'm surprised by how much  
> faster both are compared to addressing by name.
>
> This got me curious as to whether long ID would be faster than long  
> name, so I ran this:
>
> on mouseUp
>  put 100000 into n
>  --
>  put the millisecs into t
>  repeat n
>    put the long id of this cd into tID
>    put the name of tID into r1
>  end repeat
>  put the millisecs - t into t1
>  --
>  put the millisecs into t
>  repeat n
>    put the long name of this cd into tName
>    put the name of tName into r2
>  end repeat
>  put the millisecs - t into t2
>  --
>  put t1 && t2 && (r1=r2)
> end mouseUp
>
>
> ...and got this:
>
> 955 957 true
>
> So it seems that the overhead of resolving absolute object  
> references (long form) is much higher than what the engine can do  
> when you're able to hard-wire part of the reference (e.g., "...of  
> card id tID...").
>
> Historically I've often used long IDs for the convenience of having  
> an absolute object reference without regard to the type, but after  
> seeing these results I can see that there's a benefit to hard-wire  
> the type in script where practical.
>
> Thanks for bringing this up.  Learn sumpin' new every day. :)
>
>
>> Finding the problem is good of course but does anyone know why there
>> are no performance issues referring to an object by it's long name in
>> the IDE but it causes such a performance hit in a standalone?
>
> Interesting as it was to test the different ways to reference  
> objects, in practical terms I think the performance issue you  
> encountered is due to something else.
>
> The tests shown above were run in 100,000 iterations.  So while it  
> seems impressive that one took only 25% as much time as another, in  
> a given iteration the longest one took only 0.00954 ms.
>
> Unless you're addressing several hundred thousand objects at a time,  
> it's hard to imagine how the difference could product a noticeable  
> effect.
>
> I even built a standalone of the test stack, and while it was  
> somewhat slower (why would that be?) the difference between the IDE  
> and the standalone was less than 8% total, or about 0.0008 ms per  
> call.
>
> This is disappointing because it leaves the mystery unresolved,  
> unless I misunderstand something here.
>
> Can you post the section of code in question so we can see what else  
> might be at play?
>
> Also, have you compared timing tests of an isolated portion of the  
> code to hone in on where the performance is lost?
>
> --
> 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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>




More information about the use-livecode mailing list