ordinal linking for cygwin ld

[Ralf Habacker]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld_ordinal_linking_2.patch
Type: application/octet-stream
Size: 5400 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20020426/54c122fa/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld_ordinal_linking_testcase.tar.bz2
Type: application/octet-stream
Size: 5272 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20020426/54c122fa/attachment-0001.obj>