Re: [Mingw-users] Linker speed [Was: supplement to ...undefined reference to '_imp__FT_ListDevices@12']

[Wu Y. <ad...@ne...>]

Interesting. Have you tried the ld 2.14.90 that I use? My test results of 
ld 2.13.90 is consistent with yours: it is slower.

One difference between you and me is that I do not create large DLLs. My 
job for ld is mainly creation of EXEs. So the memory usage pattern could 
be different.

Also, I noticed the different ways of memory increases between ld 2.13.90 
and 2.14.90 in testing. In 2.13.90, the memory usage increases 
continuously to the peak, while in later versions the memory usage 
increases in a chunked way. So I guess there are less malloc/free calls in 
later versions, which can explain partly the speedup.

Best regards,

Yongwei

--- Original Message from Greg Chicares ---

> For a complete record, the benchmarking result for my 30-file project 
does 
> not show advantage of ld 2.15.91.  First-time linking takes 12s and 19s, 

> respectively, for 2.14.90 and 2.15.91, later linking takes 7s and 8s, 
and 
> peak memory usage is 15MB and 19MB.
> 
> So for me, the choice is obvious.  Although I guess things could change 
> for bigger projects.

My project builds a dll from
   71 object files that go into the dll
   19.7 MB size of those object files (built with -ggdb)
   15.0 MB resulting dll size
and the statistics presented here show that the newer ld is
about one-third faster, and uses six percent less memory,
for this particular project.

But what's most important to me is my application's run time,
which is about ten percent faster; that is probably not a
typical result, and a likely explanation is that I call pow()
many times. (IIRC, 3.2.3 had the slow but very accurate cephes
pow() in libmingwex.)

I used both these toolsets, which I think are the two most
recent MinGW-XXX.exe packages (I'm sure the more recent one
is the latest):

   'old' toolset:
   gcc.EXE (GCC) 3.2.3 (mingw special 20030504-1)
   GNU ld version 2.13.90 20030111

   'new' toolset:
   gcc.EXE (GCC) 3.4.2 (mingw-special)
   GNU ld version 2.15.91 20040904

and I built the dll two ways with each toolset:
   'decorated' with dllimport
   not decorated
although for both ways I linked directly to the dll.
(Later, I'll show some statistics for linking through
an import library.)

Here are my measurements:
   ld 'memory used': I watched msw 'task manager'
   ld time: output of '-Wl,--stats'
   program reports its own run times for typical tasks

'old' toolset, decorated
ld memory used, time: 138 MB, 23.031000 s
   Read input file: 69 milliseconds
   Calculate: 1546 milliseconds
   Generate and write xml output: 772 milliseconds

'old' toolset, not decorated
ld memory used, time: 138 MB, 23.015000 s
   Read input file: 61 milliseconds
   Calculate: 1563 milliseconds
   Generate and write xml output: 764 milliseconds

'new' toolset, decorated
ld memory used, time: 130 MB, 16.343000 s decorated
   Read input file: 57 milliseconds
   Calculate: 1416 milliseconds
   Generate and write xml output: 692 milliseconds

'new' toolset, not decorated
ld memory used, time: 129 MB, 16.250000 s not decorated
   Read input file: 59 milliseconds
   Calculate: 1401 milliseconds
   Generate and write xml output: 693 milliseconds

Repeating the procedure with the 'new' toolset, but using
an import library (whereas results above linked directly
to the dll), I observe:

'new' toolset, decorated, import library
ld memory used, time: 257 MB, 17.281000 s decorated
   Read input file: 59 milliseconds
   Calculate: 1411 milliseconds
   Generate and write xml output: 692 milliseconds

'new' toolset, not decorated, import library
ld memory used, time: 257 MB, 17.187000 s not decorated
   Read input file: 58 milliseconds
   Calculate: 1399 milliseconds
   Generate and write xml output: 693 milliseconds

which gives supports what the ld documentation says about
memory use at least:

 
http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-linker/win32.html

| The cygwin/mingw ports of ld support the direct linking,
| including data symbols, to a dll without the usage of any
| import libraries. This is much faster and uses much less
| memory than does the traditional import library method,
| expecially when linking large libraries or applications.

For this library, on this machine, direct linking is a few
percent faster and uses half the memory required for the
import-library method. Memory usage is very close to powers
of 2 (about 128 versus 256 MB), and I don't know whether
that's significant or accidental. It's not "much faster",
but I have a gigabyte of RAM; no doubt it would be much
faster if paging were necessary.

However, if I understand direct linking correctly, in one
practical sense it's twice as fast. In the past, I built
and maintained two separate sets of object files, one for
use with shared libraries, and one for static linking.
Now, for gcc at least, I believe I can omit the decorations
and use only one set of objects for both shared and static
linking. I had hesitated to do that in the past, because
decorations always work and there were pitfalls with other
methods (importing data, and multiple inheritance IIRC), but
now it looks like all those obstacles have been overcome
thanks to the maintainers' cleverness and hard work.