>Hi Gregory,
>
>I should have read your post before answering myself, as most of my issues were handled <bg>...
>
>Still 2 Points:
>If working on not precached table and the scenario with oodles of relations

>select  IndexExpr, FunctionToCall into array aa ;
>  where ( paddr(TableName, 32) + Triggertype = padr(m.arg1,32) + arg2 )

often is less efficient than:

>lcSelectSearch = padr(m.arg1,32) + arg2 )
>select  IndexExpr, FunctionToCall into array aa ;
>  where ( paddr(TableName, 32) + Triggertype = m.lcSelectSearch

>
>If the effort to cache the data structures is warranted, I'ld go for a global memory object instead of adding to _screen. Object redirection takes minuscle time, and this RI-Cache object could grow to more levels: if coding to insulate against tables with the same name in different dbc's [there are people doing such ugly things] it might be considered to be safer to give each dbc one such RI-Cache object.
>
>@Nadya: The transformation from table name to alias also could be cached at table or cache object level, since at the moment it is always run...
>
>regards
>
>thomas

hi Thomas,

I agree with point 1. I just gave an example.
Although I have not tested this. One could expect that the right side is only evaluated once, that would be the smart thing

point 2: I used to have global variables. You start with 1 and as time goes by their number grows.
So, a few months ago, I got rid of all of them (except 2, msg_table and msg_field that are used by field and record validation)
I have added one object to _screen (the App object) and almost everything is in there including Environment (Datasession for form.load), menu, database object, toolbar refs and much more). The nice things is, that when the object is destroyed, it closes that database, menus, etc
So, as to the minuscule object redirection time, it's a trade off, and I'm accepting it

But all in all, I think that the first thing to do in this RI, is to optimize disk IO. That will give a substantial contribution

Then, you can further optimize the performance with coding techniques like above or private variables instead of passing them to functions, etc

I use them myself, but I always do such things (except the obvious one like m.) when the prototype works and I feel I should optimize further

It's like hidden functions/properties in a class. If the class is often used or time is critical, I drop the 'hidden'