theory
To load the dynamic link library operating system must complete the following steps:
Locate the dynamic link library on disk. Take a closer look at the dynamic link library list in the application address space, and determine if the dynamic link is loaded. Assign the dynamic link library to resident memory and map the dynamic link library binary to the memory (in Windows NT, mapping across the segment object). To make the dynamic link library run normally, perform a series of necessary processing (for example, resolving the corrections made in the dynamic link library, etc.).
Different parameters determine that the load time of the dynamic link library is different. The following is given to various factors that need to be considered. In fact, some factors may also affect the load time of the dynamic link library:
Bottom hardware and hardware: The speed of the computer itself and which operating system runs. Status of current systems and applications: The tight condition of the system in the virtual memory, and whether the dynamic link library can be loaded in the preferred base address. Dynamic link library itself: How big is the dynamic link library itself, how many locations in the dynamic link library require a correction (combined with the integrated considerations), this dynamic link library is implicitly linked to the other dynamic link library that needs to be loaded.
It can be seen from the above analysis that the base reset for a dynamic link library is by no means a unique determinant that affects the dynamic link library loading time. In this article, the authors use a lot of data, indicating that the dynamic link library load time change range and the application may affect the load time.
The reader should notice that the base reset for a dynamic link library, it may not only increase the increase in the load time, but also increase the expenditure of the page file. The first step of loading the dynamic link library, you need to create a section object (section object), and the segment object is supported by the dynamic link library, and an adjacent segment in the memory. Once a page of the dynamic link library is removed from the application work set, the operating system will reload this page from the dynamic link library executable next time.
Of course, this policy is no longer playing when the dynamic link library is reset, which is mainly because the page containing the reset address is different from the corresponding page in the dynamic link library executable file map. Therefore, once the executable file is loaded, the operating system attempts to correct the address, it will copy the corresponding page (since the section is opened through the COPY_ON_WRITE flag). All modifications performed in the copy, the operating system will remember, from now on, the page will be swapped in the system page file, and no longer exchange in the executable image.
With this mechanism, there are two potential performance hits: First, each page containing the reset address is taken up a page file (its result is to reduce the number of virtual memory available for all applications); Since the operating system performs the first correction operation in the dynamic link library page, the new page must be allocated from the page file and copy the entire page.
Although the scanning dynamic link library recipient segment and algorithms that perform memory corrections have high efficiency, perform a correction operation or increase the loading time of the dynamic link library. (The complexity of span operations is a linear function of repairing the number of addresses.)
Address correction
The problem with the dynamic link library base reset is, "What is the meaning of the address correction? Is the programmer adjust the code to reduce the address correction in the executable program?" For these two questions The answer is that all this depends on which platform is based on the executable. In this article, we limit the platform on Intel 386,, 486, and Pentium processors to discuss the corresponding executable. (Note: For other platforms, the corresponding address repair concept is different from the concept discussed in this article.) On 386, 486, or on the Pentium processor, two situations may result in an address being identified as "relocation positioning "Status: First, static objects, another situation is absolute jump (ABSOLUTE JUMPS).
First, if the dynamic link library references a static object, the absolute address of the object (assuming the dynamic link library is loaded into the preferred address). For example, in the following code segments:
LPSTR LPNAME = "Name";
The load program of the dynamic link will assign the "name" string into the dynamic link library data segment and fill in the starting address of this string to the position corresponding to the LPNAME variable. If the "Name" string must be relocated because the DLL cannot be loaded into the base site, the LPNAME must be adjusted accordingly. Note that in this case, the variables of each reference segment must also be corrected accordingly.
Objects that can be relocated include text strings (eg, "Name" strings in the above example, any type of global or static data, including static allocation C objects. It should be noted that in particular in C , there may be many cross-indexes from a static object to another static object. Data that are not initialized does not need to correct the address during the relocation process, but pointing to an index that is not initially static data requires address correction.
In the I386 executable code, the other class can be relocated is an absolute jump and function call, including system function calls. Note that the program developers are difficult to avoid address relocation by modifying the program code, the only way to use is the number of static allocation data. To reduce static allocation data, one way is to avoid using the name for resource indexing, but should be resource index through the coordinates (because each name explicitly used in the code will automatically become a heavy positionable item. ).
Nevertheless, the author does not recommend developing dynamic link library code with a special purpose of loading time, unless there are two situations: (1) The data of the static allocation target can be greatly reduced; (2) programmer When programming in this manner, it does not affect the factors that need to be considered in other programming.
In addition, program developers can reduce loading time by simple optimization methods. For example, all data that can be repositioned can be set to a few pages. Obviously, if the dynamic link library needs to be reset, each page contains two pages of a relocation item, you need a page file to support. If all the relocation items appear on the same page, only one page requires page files to support, so only one page will be affected. In the case of necessary cases, the reader can use the Pragma (Data_SEG, Data Section) pseudo instruction to ensure that as many recruitable items as possible are allocated as few pages as possible.
