Mail Archives: cygwin-apps/2002/04/28/08:13:18
Ralf Habacker
> -----Original Message-----
> From: kde-cygwin-admin AT mail DOT kde DOT org
> [mailto:kde-cygwin-admin AT mail DOT kde DOT org]On Behalf Of Robert Collins
> Sent: Saturday, April 27, 2002 8:44 PM
> To: Ralf Habacker; Charles Wilson
> Cc: Kde-Cygwin; Binutils; Cygwin-Apps
> Subject: RE: ordinal linking for cygwin ld
>
>
>
>
> > -----Original Message-----
> > From: Ralf Habacker [mailto:Ralf DOT Habacker AT freenet DOT de]
> > Sent: Sunday, April 28, 2002 4:28 AM
> > >
> > > Hangon, lets go back a bit. Why do you want ordinal-only
> > linking? For
> > > runtime or link-time performance?
> Or for on-disk import > > library size?
Besides the faster load time associated with importing and exporting by ordinal,
there's another more subtle benefit. When exporting an API by ordinal, you can
tell the linker not to store the exported API name in the exporting DLL. This
means a smaller export section, and potentially a smaller binary with less data
to demand page in. To eliminate the API name, use the NONAME modifier when
exporting by ordinal.
....
If you look at MFC42.DLL, you'll see that it exports almost all of its 6000+
APIs by ordinal, and with the NONAME modifier. Imagine the added bulk if
MFC42.DLL had to store all 6000 mangled C++ names in its exports!
> > > Or....
> > runtime performance
>
> Ok, well then check this :
> http://msdn.microsoft.com/msdnmag/issues/0500/hood/hood0500.asp article
> out.
>
> Linking by ordinal only gives a 2%-4% improvement. rebinding and
> rebasing gives up to 18%.
>
from this article:
" Before getting to the actual numbers, let me first say that I was amazed at
how fast programs can load. I intentionally created LoadTimeTest.EXE to make a
lot of work for the Win32 loader. It has a fair number of DLLs and lots of
exported functions and relocations. Even under the slowest scenario, my machine
still loaded the program under Windows 2000 in less than 1/50th of a second.
If your program takes a long time to load, don't blame the loader. The problem
is almost certainly that somebody's initialization code is taking too long.
He does testing with short named c functions. C++ function names are much
longer. Additional the problem is the first loading, calling again works fast in
any way. (Except of the binary size) See below.
<snip>
make shortnames -> 13 character function names
$ time ./client.exe
real 0m1.392s
user 0m0.010s
sys 0m0.000s
$ time ./client.exe
real 0m0.032s
user 0m0.020s
sys 0m0.010s
make longnames -> 403 character function names
$ time ./client.exe
real 0m6.990s
user 0m0.020s
sys 0m0.000s
habacker AT BRAMSCHE ~/src/ld-contrib/ld-bugfi
$ time ./client.exe
real 0m0.065s
user 0m0.020s
sys 0m0.000s
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
habacker AT BRAMSCHE ~/src/ld-contrib/ld-bugfix-test
$ ls *.exe *.dll -l
-rwxrwxrwx 1 1002 Kein 2188288 Apr 28 14:00 client.exe
-rwxrwxrwx 1 1002 Kein 128512 Apr 28 14:00 clientordinal.exe
-rwxrwxrwx 1 1002 Kein 2273280 Apr 28 14:00 dll.dll
-rwxrwxrwx 1 1002 Kein 2273280 Apr 28 14:00 dllordinal.dll
In the dll avoiding the IMAGE_IMPORT_BY_NAME structure would save 2MB in the
dll.
BTW: Do you know why the exports in the dll are necessary ? Does the implib not
contain this stuff already, so they could be removed ?
> So linking by ordinal only will help you a little. rebinding and
> rebasing your .dll's will help much much more.
.. which has to be analysed. Has anyone a working bind app ?
Ralf
- Raw text -