See answers below.
Pete Haworth
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")?
Here's writeDebug and another function it calls getprefsFolderPath.
command writeDebug pText
put getprefsFolderPath("BandTrak") & "debuglog.txt" into
myPrefsFilePath
write pText & return to file myPrefsFilePath
end writeDebug
function getPrefsFolderPath pSubFolder
if the environment is "development" then
put the effective filename of this stack into prefsFolder
set the itemdelimiter to slash
put item 1 to -2 of prefsFolder into prefsFolder
else
if the platform = "MacOS" then
put specialFolderPath("Preferences") into prefsFolder
else if the platform = "Win32" then
put specialFolderPath(26) into prefsFolder
end if
end if
if last char of prefsFolder is not "/" then
put slash after prefsFolder
end if
if the environment is not "development" then
put pSubFolder & slash after prefsFolder
end if
return prefsFolder
end getPrefsFolderPath
I didn't put the rest of the repeat lop in the example because the
timing ends at the top of the repeat loop. I can give you the code
but it's basically executing an SQLite SELECT statement. There's
another time measurement at the completion of the SELECT and it
indicates there's no significant difference between the IDE and the
standalone for the SELECT execution.
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?
A little background for you. This code is part of a library routine I
have to load values from an SQLite SELECT statement into controls on
the form. All the controls on the form that relate to columns in the
selected row start with DB_ followed by the name of the column. In
the IDE, whenever a card is opened, I create a list of the DB_
controls and store them in a custom property named fieldList, one per
line. I'm currently storing the long name of each control in
fieldList and I can see that they are in the correct format in the
custom property. There's an outer loop that processes every line in
fieldList to load the data into the controls and to help track this
down, I put the following statement in that loop:
put the ID of myControl into myID
myControl is the variable that holds one line from the fieldList
custom property. I guess that's a long winded way of saying yes, the
long name formats look correct. I haven't checked myID to see if it
holds an integer but unless the put statement is doing something
weird, I'm pretty sure it does.
Also, do you have any getProp handlers in your stack?
I do have some getProp and setProp handlers but not for the properties
used in this section of code. I had wondered if there was something
of that nature happening, so I stepped through every line of code in
debug to make sure it wasn't dashing off into some hidden direction
like that and I didn;t see anything of that nature.
Perhaps most importantly: are there any other stacks or libraries
used by the standalone that aren't present in the IDE?
I don;t think so, certainly not intentionally,but I'm not sure how to
tell. I used the Stacks tab of the Standalone Application Settings to
set the stacks other than the main application stack that were to be
included in the standalone.
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.
OK I did that. Here's the output from the IDE"
FrontScripts
card id 1004 of stack "/Users/Dad/RevDev/Code Library.rev"
card id 1003 of stack "/Users/Dad/RevDev/Code Library.rev"
card id 1002 of stack "/Users/Dad/RevDev/Code Library.rev"
button id 1117 of group id 1016 of card id 1002 of stack "/
Applications/LiveCode 4.5.app/Contents/Tools/Toolset/revlibrary.rev"
button id 1116 of group id 1016 of card id 1002 of stack "/
Applications/LiveCode 4.5.app/Contents/Tools/Toolset/revlibrary.rev"
button id 1109 of card id 1002 of stack "/Applications/LiveCode
4.5.app/Contents/Tools/Toolset/revlibrary.rev"
button id 1042 of card id 1002 of stack "/Applications/LiveCode
4.5.app/Contents/Tools/Toolset/revlibrary.rev"
stack "/Applications/LiveCode 4.5.app/Contents/Tools/Toolset/
revdebugger.rev"
BackScripts
button id 1118 of group id 1016 of card id 1002 of stack "/
Applications/LiveCode 4.5.app/Contents/Tools/Toolset/revlibrary.rev"
button id 1037 of group id 1016 of card id 1002 of stack "/
Applications/LiveCode 4.5.app/Contents/Tools/Toolset/revlibrary.rev"
button id 1018 of group id 1016 of card id 1002 of stack "/
Applications/LiveCode 4.5.app/Contents/Tools/Toolset/revlibrary.rev"
button id 1017 of group id 1016 of card id 1002 of stack "/
Applications/LiveCode 4.5.app/Contents/Tools/Toolset/revlibrary.rev"
button id 1015 of group id 1016 of card id 1002 of stack "/
Applications/LiveCode 4.5.app/Contents/Tools/Toolset/revlibrary.rev"
button id 1014 of group id 1016 of card id 1002 of stack "/
Applications/LiveCode 4.5.app/Contents/Tools/Toolset/revlibrary.rev"
button id 1013 of group id 1016 of card id 1002 of stack "/
Applications/LiveCode 4.5.app/Contents/Tools/Toolset/revlibrary.rev"
stack "/Applications/LiveCode 4.5.app/Contents/Tools/Toolset/
revonlinelibrary.rev"
stack "/Applications/LiveCode 4.5.app/Contents/Tools/Toolset/
revdocumentationlibrary.rev"
stack "/Applications/LiveCode 4.5.app/Contents/Tools/Toolset/
revmetadata.rev"
button id 1041 of card id 1002 of stack "/Applications/LiveCode
4.5.app/Contents/Tools/Toolset/revlibrary.rev"
button id 1120 of card id 1002 of stack "/Applications/LiveCode
4.5.app/Contents/Tools/Toolset/revlibrary.rev"
In Use
(Notice nothing listed under in USe - I think this may be because the
logging was doen in the preOpenCard of the card in the main stack?)
Here's the output from the standalone:
FrontScripts
card id 1004 of stack "/Applications/BandTrak1/BandTrak.app/Contents/
MacOS/Code Library.rev"
card id 1003 of stack "/Applications/BandTrak1/BandTrak.app/Contents/
MacOS/Code Library.rev"
card id 1002 of stack "/Applications/BandTrak1/BandTrak.app/Contents/
MacOS/Code Library.rev"
button id 90449 of group id 90444 of card id 90399 of stack "/
Applications/BandTrak1/BandTrak.app/Contents/MacOS/BandTrak"
button id 90448 of group id 90444 of card id 90399 of stack "/
Applications/BandTrak1/BandTrak.app/Contents/MacOS/BandTrak"
BackScripts
button id 90447 of group id 90444 of card id 90399 of stack "/
Applications/BandTrak1/BandTrak.app/Contents/MacOS/BandTrak"
button id 90446 of group id 90444 of card id 90399 of stack "/
Applications/BandTrak1/BandTrak.app/Contents/MacOS/BandTrak"
button id 90445 of group id 90444 of card id 90399 of stack "/
Applications/BandTrak1/BandTrak.app/Contents/MacOS/BandTrak"
In Use
Copy of revErrorReport
revExternalLibrary
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).
Interesting. As mentioned above, I do have perhaps a dozen getProp/
setProp handlers but none for the custom properties used in this
section of the code. Once again though, if there is a slowdown
because of that, you'd expect it to be the same in the IDE and
standalone.
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.
OK, I'll gve that a whirl, but it will mean changing my code to go
back to using the long names again so will need a little time to take
care of that.
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. :)
Hopefully indeed!
--
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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
