ToolBook will "get" a system or local variable about 250,000 times in one second (on my machine) but most of that is taken by the step structure used to time it. In other words, it takes almost no time at all. A "to get" function that just returns a value (in the same script as the call) takes about the same amount of time. It takes 40 times as long to test an "if" (that doesn't do anything) or to get an object's name. Getting the text of a field takes much longer (2000 times per second for 20 words). It takes 200 times as long to get a user property (1,250 per second)... and 250 times for a longer user property with ten items in a list. It takes about ten percent longer still to get one user property if the object has ten user properties. Setting user properties takes yet another 20 percent longer than getting them (833 per second).
Does anyone else find this stuff fascinating? I guess 250 times a poofteenth of a second is still a very short time but it must add up. When speed is an issue (and when isn't it?), should we minimise the use of user properties? If user properties are for some reason unavoidable, maybe all the necessary stuff should be put into one long user property and shoved into a variable before any further code is executed (eg on enterPage or enterBook). Has anyone had much experience using INI files and system variables? Does that work out quicker/better than user properties for this kind of information storage?
Because object names are so much more readily available than user properties, a carefully considered object naming standard using suffixes for various parameters might seem a reasonable compromise.
On the subject of code placement, it doesn't take any longer to send a buttonClick to the book script than to an object on the page but the time doubles if you let it go through to a system book. Kinda makes you wonder if it might be better to use more code in more objects rather than buried deep in system books but I suppose there'll always be a trade-off between speed, file size and ease of maintenance.
Many of the issues raised on this list highlight the need for very carefull planning.
jeff parkes jparkes@vcrpmap.telecom.com.auDoes anyone else find this stuff fascinating?
Yes
I think you might be getting a little carried away. Just because it takes a
couple hundred milliseconds to access a user property instead 1 to access a
variable I wouldn't say that we need to reduce the number of user
properties. I would, however, definitely modify just how often I use them.
I approach this with what I call caching the property.
For example:
to handle doit
step i from 1 to charCount(text of field "Test")
if char i of text of field "Test" is in space&tab&CRLF
clear char i of text of field "Test"
end if
end step
end
Could be written as
to handle doit
local string temp
temp = text of field "Test"
step i from 1 to charCount(temp)
if char i of temp is in space&tab&CRLF
clear char i of temp
end if
end step
text of field "Test" = temp
end
The second handler is a lot faster than the first.
I hope this helps!David Kester