Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: <kde-cygwin AT mail DOT kde DOT org>, "Binutils" <binutils AT sources DOT redhat DOT com>,
   "Cygwin-Apps" <cygwin-apps AT cygwin DOT com>
Cc: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>,
   "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Subject: RE: ordinal linking for cygwin ld
Date: Sun, 28 Apr 2002 14:12:50 +0200
Message-ID: <001a01c1eeae$04741080$d36707d5@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <FC169E059D1A0442A04C40F86D9BA7600C5F38@itdomain003.itdomain.net.au>
Importance: Normal



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