Kbase P161707: Calling user-defined functions in a super procedure stack has high overhead
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
23/03/2010 |
|
Status: Unverified
SYMPTOM(s):
Calling user-defined functions in a super procedure stack has high overhead
Single call using a function prototype (FUNCTION .... IN <handle> definition) takes 20 milliseconds
Single call using a DYNAMIC-FUNCTION takes 20 milliseconds
All super-procedures contain prototype FUNCTION .... IN <handle> declaration
For all super-procedures the handle at runtime points to the procedure at the bottom of the hierarchy
FACT(s) (Environment):
OpenEdge 10.2x
All Supported Operating Systems
CAUSE:
This is expected behavior.
The function prototypes defined with the "IN <handle>" option will be added to the INTERNAL-ENTRIES of a procedure. This means that as far as the runtime is concerned, there will be multiple procedures where the function can be called, and the runtime is not capable of immediately determining the actual implementation based on the name. Instead, if one of the prototypes is called, the call will be redirected to the context specified by the handle - in this case the procedure at the bottom of the hierarchy.
When the function is called, the runtime steps into the first super-procedure where the function is found. If this is a prototype,the runtime steps back to the bottom procedure and from there into the next super-procedure with the function.
This repeats until the actual function implementation is called instead of a prototype.
It's this stepping in and out of super-procedures that introduces the overhead.
FIX:
The key to resolving the performance bottleneck is avoiding the stepping in and out of super-procedures.
The recommended approach is to perform the following steps:
- Rename the actual implementation of the function, ensuring it's name is unique to the application.
- Update the prototype definitions, and include the MAP TO option specify the new name of the actual implementation, leaving the original function name unchanged.
The result of this is that after the first step into a super-procedure with a function prototype, the runtime will be searching for a function with a different. unique name and will ignore any super-procedure that only defines the prototype.
This approach also requires the fewest code changes in an existing codebase.
An alternative approach is to ensure the handle variables used in the super procedures point to the procedure with the actual function implementation, rather than the bottom of the hierarchy. Theoretically this provides the best performance on the actual function calls, but the downside is that managing the procedure handles and contexts becomes significantly more complex.