>(0) please define 'outside' and 'inside' the application
>
>Inside by way of timers or a coverage log of an area with many calls to the function in question.
>
>Outside by way of setting procedure only to the library of the function and calling it in a loop. One possibility is that Fox caches the function when it's called repeatedly but un-caches it when it's being called in the application since in the application we have lots of code called between each call to the function.
>
>Naomi mentioned that having multiple "set procedures" in memory (for us roughly 30) and/or multiple "set classlib" set could slow us down. If that's the case then we're pretty much screwed. There's no way we can clear out our classlibs and libraries everytime we call the function.

That should not be a problem imo, just make the file that has your function the first in the set proc


>(1) Prefix all variables including object references, (even functions maybe) with m.
>
>I've seen this done with the generated code when you create an assign/access method for a property. What does this accomplish?

It speeds up your code. If the variables are not m.prefixed then the search starts in the field list of an open table/cursor in select(0)
See: http://fox.wikis.com/wc.dll?Wiki~EssentialMDot~VFP

>(2) Any way to avoid the call, ie work with a #define so that the code is repeated in a 'controlled' way
>
>We're currently working a solution that heads in this direction. The function in question retrieves data from meta tables for us. We're trying a dynamic load solution that scatters the meta-table record in question to an object wherein we can simply evaluate an object.property reference to get the values we're after instead of calling the function. Unfortunately this means rewriting a lot of code.

Do you use seeks(), if so

lparameters key

&& do not check for an open table and then open it if needed, open it only once in another function
if( seek(m.key, table, index ) )
   return Table.field
else
  return ???
endif

&& is slower than

if( (Table.key == m.Key) or seek(m.key, table, index ) )
  return Table.field
else
  return ???
endif

I would not go for the 'object.property' route. Too many objects slow down, many scatters slow down

>(3) Passing parameters takes time as well, especially (long) strings
>
>N/A
>
>(4) Are the calls in an object, ie something like =m.this.Function() and Function() is hidden/protected ?
>Take the hidden/protected away. It's not 'very' clean, but it speeds up
>
>N/A. This is a function in a prg.
>
>(5) when calling object methods or accessing their properties multiple times, sometimes 'with / endwith' can help.
>If it is only a couple of times, with/endwith tend to slow it down
>
>See previous.
>
>(6) a piece of code might help, ie the function and how it is called
>
>Unfortunately I can't do that, and like I said the internals of the function are extremly fast. It opens an indexed table, seeks, and returns. I can offer this:
>
>GetMyMetaInformation( tcDatabaseFieldName, tcMetaFlag, tcMetaField )
>
>ie: GetMyMetaInformation( 'inspections.reading', 'U', 'caption' ) would return the stored caption for inspections.reading which is a calculated ("U") field.