This section contains some hints on using DLLs efficiently. Effective
use of DLLs may improve the performance of your application. Following
are some suggestions that may improve performance:
- If you are using a particular DLL frequently across multiple address
spaces, the DLL can be installed in the LPA or ELPA. When the DLL
resides in a PDSE, the dynamic LPA services should be used (this will
always be the case for XPLINK applications). Installing in the LPA/ELPA
may give you the performance benefits of a single rather than multiple
load of the DLL
- When writing XPLINK applications, avoid frequent calls from XPLINK
to non-XPLINK DLLs, and vice-versa. These transitions are expensive,
so you should build as much of the application as possible as either
XPLINK or non-XPLINK. When there is a relatively large amount of function
calls compared to the rest of the code, the performance of an XPLINK
application can be significantly better than non-XPLINK. It is acceptable
to make calls between XPLINK and non-XPLINK, when a relatively large
amount of processing will be done once the call is made.
- Be sure to specify the RENT option when you bind your code. Otherwise,
each load of a DLL results in a separately loaded DLL with its own
writable static. Besides the performance implications of this, you
are likely to get incorrect results if the DLL exports variables (data).
- Group external variables into one external structure.
- When using z/OS® UNIX avoid unnecessary load attempts.
z/OS Language Environment® supports
loading a DLL residing in the UNIX file system or a data set. However,
the location from which it tries to load the DLL first varies depending
whether your application runs with the runtime option POSIX(ON) or
POSIX(OFF).
If your application runs with POSIX(ON),
z/OS Language
Environment tries
to load the DLL from the UNIX file system first. If your DLL is a
data set member, you can avoid searching the UNIX file system directories.
To direct a DLL search to a data set, prefix the DLL name with two
slashes (//), as shown in the following example.
//MYDLL
If
your application runs with POSIX(OFF),
z/OS Language
Environment tries to load your DLL
from a data set. If your DLL is a UNIX file system file, you can avoid
searching a data set. To direct a DLL search to the UNIX file system,
prefix the DLL name with a period and slash (./), as shown in the
following example.
./mydll
Note: DLL names
are case sensitive in the UNIX file system. If you specify the wrong
case for your DLL that resides in the UNIX file system, it will not
be found in the UNIX file system.
- For IPA, you should only export subprograms (functions and C++ methods)
or variables that you need for the interface to the final DLL. If
you export subprograms or variables unnecessarily (for example, by
using the EXPORTALL option), you severely limit IPA optimization.
In this case, global variable coalescing and pruning of unreachable
or 100% inlined code does not occur. To be processed by IPA, DLLs
must contain at least one subprogram. Attempts to process a data-only
DLL will result in a compilation error.
- The suboption NOCALLBACKANY of the compiler option DLL is more efficient
than the CALLBACKANY suboption. The CALLBACKANY option calls z/OS Language
Environment at
run time. This runtime service enables direct function calls. Direct
function calls are function calls through function pointers that point
to actual function entry points rather than function descriptors.
The use of CALLBACKANY will result in extra overhead at every occurrence
of a call through a function pointer. This is unnecessary if the calls
are not direct function calls.