Subject: Re: dlltool & memory hoggage
From: Sigbjorn Finne <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 6 Aug 1999 10:41:11 +0100 (BST)

Paul Sokolovsky writes:
> 
> 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.
> 

Thanks for the info, Paul. Had a look around and it's the creation of
an import library which turns "dlltool" into such a dog, chaining
together a looong list of "bfd"s before writing out the archive. I
notice that DJ's (much appreciated) changes to "ld" to have it support
DLLs uses the same scheme, so my *guess* is that it will have similar
memory behaviour.

Reusing 'ar q' hacks seems like the way to go here, but holidays are
getting in the way of me having a go with this now.

cheers,
--sigbjorn

--
Want to unsubscribe from this list?
Send a message to [email-masked]