Hi all, one of the biggest problems with kde 2.2.x currently is the very bad loading time of applications and dll's, I've investigated some time to analyse this. On this way I recognized, that runtime linking using symbol names is one of the major time eater.
At first I have tried to estimate the influence of symbol name to the runtime linking time. So I have build a dll 5000 functions and a client app, which uses this functions. This dll/apps are compiled in two variants, 1. with a symbolname lenght of a 13 characters and 2. with a symbolname lenght of 403 characters (should simulate long c++ names). cd shortname time ./client.exe real 0m0.772s user 0m0.030s sys 0m0.030s $ cd longname $ time ./client.exe real 0m15.182s user 0m0.060s sys 0m0.040s The result shows that this has a great effect of app/dll loading time (about 20 times more). After thinking a while about this, I remembered, that the windows pe format allows two runtime linking types. The first, usually used, is linking by the symbol name, the second is linking by symbols ordinal. A look in the last official cygwin ld (20011002) source shows, that linking by ordinal seems to be prepared with one limitation. There is no command line switch to create an import library for ordinal linking on dll building, so I've added a switch --out-implib-ordinal <filename>. (BTW: Another possibibily was automatic ordinal linking. See later) Now I've tried a second test. 5000 functions with symbolname lenght of 403 characters linked 1. with names and 2. with ordinals. 5000 functions with symbol name linking (symbols not stripped) $ time ./client.exe real 0m15.182s user 0m0.060s sys 0m0.040s 5000 functions with ordinal linking (symbols not stripped) $ time ./client.exe real 0m0.572s user 0m0.020s sys 0m0.030s Wow, thats great. 1. Currently I' have a working solution for binutils 20011002 using a specific import library create with an -out-implib-ordinal option, which contains only ordinals and no symbols in the IMPORT_DESCRIPTOR_BY_NAME structure. (The patches and testcase are appended) 2. Another possibility is using the regular import libraries hint number for ordinal linking (hint number = Ordinal number-1), but currently I don't know if this is always true. Solution 1 has an advantage on building big c++ libs, because the import library are smaller (about 20-50%). See the following example. The amount depends on the symbols count and length. old -rwxr-xr-x 1 1002 Kein 1682944 Apr 22 09:42 /opt/kde2/bin/cygkdecore-3.dll -rwxr-xr-x 1 1002 Kein 3190016 Apr 20 19:12 /opt/kde2/lib/libkdecore.dll.a new -rwxrwxrwx 1 1002 Kein 1956812 Apr 26 22:03 libkdecore.dll.a -rwxrwxrwx 1 1002 Kein 1608192 Apr 26 22:28 cygkdecore-3.dll Solution 2 is full compatible to dll's builded with previous ld, because the dll and import lib are still the same. Compiling an app with new ld will automatically use ordinal linking. The only necessary point seems to me a command line switch to switch of this behavior. Any comments ? Regards Ralf
ld_ordinal_linking_2.patch
Description: Binary data
ld_ordinal_linking_testcase.tar.bz2
Description: Binary data