Performance Mystery Solved - IT'S THE DATA STUPID!!

[Bob Sneidar]

Yay! Nice catch. You had me going there for a while. I wonder though how this would affect a standalone which uses sqlYoga? As I mentioned, sqlYoga uses the long ID of the button object that stores the database objects as properties. 

Seems to me however that it might be better to just let the engine do what it was designed to do, that is resolve the object references on the fly, instead of storing them in properties. But I have no knowledge of your app or it's inner workings so that may be simplistic. 

Bob


On Nov 11, 2010, at 4:43 PM, Peter Haworth wrote:

> Figured out the IDE/Standalone performance issue, it's nothing to do with the code.
> 
> I my last email I mentioned how I have a custom property holding the long names of all the controls on a card that need to have data loaded into them from my database.  On closer inspection, the long name includes the name of the stack file which - duh - is my .rev file!!!  So when the standalone gets the long name of a control from the custom property, it is referencing the control in my.rev file, not the control in the standalone, and presumably has to go open the .rev file every time my code refers to a control.  No wonder everything took longer.  Using the ID removes that problem of course.
> 
> I still have to figure out what to about this.  I can either change my code to use the ID everywhere instead of the long name, or I can somehow parse out the the part of the long name that is the path to my .rev file.  Or I could build the list of controls in the standalone (currently it specifically doesn't do that on the grounds that it didn't need to).
> 
> Sorry for the false alarms!
> 
> Pete Haworth
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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