The shared-library capability sometimes provides an opportunity to make time and memory trade-offs.
The idea behind shared libraries is to have only one copy of commonly used routines and to maintain this common copy in a unique shared-library segment. This can significantly reduce the size of executables, thereby saving disk space. In addition, since these common routines are used by many processes in a multiuser environment, the routine may already be in real memory when you first reference it. In that case, the time it takes to page fault the subroutine into real memory and the page frame it would occupy are saved. Another advantage to shared libraries is that the routines are not statically bound to the application but are dynamically bound when the application is loaded. This permits applications to automatically inherit changes to the shared libraries, without recompiling or rebinding.
There are, however, possible disadvantages to the use of shared libraries. From a performance viewpoint, there is "glue code" that is required in the executable to access the shared segment. This code adds a number of cycles per call to a shared-library segment. A more subtle effect is a reduction in "locality of reference." You may be interested in only a few of the routines in a library, and these routines may be scattered widely in the virtual address space of the library. Thus, the total number of pages you need to touch in order to access all of your routines is significantly higher than if these routines were all bound directly into your executable. One impact of this is that, if you are the only user of these routines, you experience more page faults to get them all into real memory. In addition, since more pages are touched, there is a greater likelihood of causing an instruction translation lookaside buffer (TLB) miss.
The cc command defaults to the shared-library option. To override the default, use the -bnso option as follows:
cc xxx.c -o xxx.noshr -O -bnso -bI:/lib/syscalls.exp
The obvious method of determining whether your application is sensitive to the shared-library approach is to recompile your executable using the nonshare option. If the performance is significantly better, you may want to consider trading off the other advantages of shared libraries for the performance gain. Be sure to measure performance in an authentic environment, however. A program that had been bound nonshared might run faster as a single instance in a lightly loaded machine. That same program, when used by a number of users simultaneously, might increase real memory usage enough to slow down the whole workload.
Shared Libraries and Shared Memory in AIX Version 4.3 General Programming Concepts: Writing and Debugging Programs.