Performance and Debugging Tips 

The following sections describe techniques you can use to improve the performance and reduce debugging time for your applications.

Avoiding Unnecessary Object Creation

Application objects and all collection objects are created dynamically when your code makes a reference to one of them. These objects are temporary and are destroyed when no more references to them exist. As a result, multiple accesses to one of these objects can affect performance. To avoid this problem, assign the object to an object variable of your own and then make the accesses.

You can improve the code

GetFunct.Exports( " P1 " )

GetFunct.Exports( " P2 " )

GetFunct.Exports( " P3 " )

GetFunct.Exports( " P4 " )

GetFunct.Exports( " P5 " )

by changing it to

set MyExports = GetFunct.Exports

MyExports( " P1 " )

MyExports( " P2 " )

MyExports( " P3 " )

MyExports( " P4 " )

MyExports( " P5 " )

In the first section of code, five temporary collection objects are created, and each is destroyed after a single statement. In the second section, only one temporary object is created. (This object is not destroyed after the first statement, because the other statements still refer to it.)

Tracing RFC Calls

You can request a trace of connection activity as the RFC call executes. The TraceLevel property in the Connection object lets you specify tracing. Possible values are 0 (tracing not requested) and 1 (tracing requested).

The activity information is logged in a file "RFC<random number>.TRC" located in the active default directory.

The Functions collection and Transactions collection objects also provide logging functionality with the LogFileName and LogLevel properties.

Note on Embedded Property Calls

When coding your application, you should be aware that client languages may execute certain kinds of statements differently. Of particular importance is whether or not your language performs cascaded evaluation in the form of statements like:

MyFunct.Exports( " P1 " ).Value( " F1 " )

This statement requires the language to first call the Exports property for MyFunct. When a Structure object is returned, you call the Value property on the Structure object.

Some languages do not perform full evaluation of statements. They evaluate the first call (the Exports property), but do not evaluate the returned value (a Parameter or Structure object) to call the next property (Value method) on it. As a result, you get the wrong object returned, and eventually a runtime error.

The Excel macro language executes the above statement correctly, but Visual Basic 3.0 does not. However, almost all interpreters fail to evaluate statements correctly when a default function is left implicit:

GetFunct.Exports( " P1 " )( " F1 " )

Note on Default Property Calls

Some languages do not evaluate the default value property. In this case, the default value property must be explicitly specified:

MyFunct.Exports( " P1 " ) ‘ Does not work.’

MyFunct.Exports.Item ( " P1 " ) ‘ OK’