I think I have found the cause of the performance problems I have
been experiencing. I had been referring to objects by their long name
in various places in the offending code. I started changing the code
to refer to the same objects by their short ID and each line of code I
changed
Again, Peter, I think you have hit on something here. Good detective work. So
it was not the SQL queries that were causing the delay? Good to know. I think
it is a bug of some kind, but then I am the Bugmeister, so that is expected.
I would submit a bug and see where it goes.
Bob
On Nov
Peter Haworth wrote:
I think I have found the cause of the performance problems I have
been experiencing. I had been referring to objects by their long name
in various places in the offending code. I started changing the code
to refer to the same objects by their short ID and each line of
Yeah, and Peter's issue was that with standalones, the problem is many orders
of magnitude worse.
Bob
On Nov 11, 2010, at 11:04 AM, Richard Gaskin wrote:
So it seems that the overhead of resolving absolute object references (long
form) is much higher than what the engine can do when
Bob Sneidar wrote:
On Nov 11, 2010, at 11:04 AM, Richard Gaskin wrote:
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...).
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:
myIDholds the short ID of the control
pselection a parameter passed into the command
put the milliseconds into
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:
myIDholds the short ID of the control
pselection a parameter passed into the command
put the milliseconds into mymilliseconds
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
