Mail Archives: cygwin/1999/08/05/09:59:10
Hello Sigbjorn,
Sigbjorn Finne <sof AT dcs DOT gla DOT ac DOT 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
P.S.
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 AT is DOT lg DOT ua
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -