dlltool & memory hoggage

Paul Sokolovsky paul-ml@is.lg.ua
Thu Aug 5 06:56:00 GMT 1999

Hello Sigbjorn,

Sigbjorn Finne <sof@dcs.gla.ac.uk> wrote:

SF> Hi,

SF> I wondered whether anyone's had a look at why dlltool consumes so much
SF> VM when executing? When building DLLs with 100s (and in some cases
SF> 1000s) of exported entry points, I'm seeing images that often are >
SF> 50M in size (this is with both B20.1's dlltool.exe and one built from
SF> the latest binutils src snapshot.)

SF> Before I have a go at trying to chase this one down, I'd be very
SF> interested to hear from people that have investigated this one already
SF> and what the findings were.

    I work on large C++ project and last thing I did was dll support
for it. With gcc 2.95's support for building C++ dlls, I had about 300k per
object, 18M total. Linking them into dll took more than 40 minutes on
PII-300/64M. As you understand, it was completely swap trashing. I
must admit that every module had very mush stuff included
(corresponding .ii was about 0.5M) and I tried to drop superfluous.
With some effort I cut object set to 9M and linking time to 5
minutes. However, when I uploaded stuff to tiny P100/24M, I was unable
to link until I provided 48M of swap, and after that it took 1,5 hours
to complete.

    Additional info: win95 was used in both cases. My own build of ld
with djgpp's malloc (with GlobalAlloc() as morecore()) was used.

    Resume: GNU ld, or more specifically, bfd, seem to use not very
efficient memory management techniques (probably malloc'ing much
little objects), which behaves badly with overoptimized MS OS's.

SF> thanks,
SF> --sigbjorn

By the way, don't you think that even building import library from
mere .def takes _too_long_? I may suppose so.

Best regards,
 Paul                            mailto:paul-ml@is.lg.ua

Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

More information about the Cygwin mailing list