Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Archive:	<http://sourceware.cygnus.com/ml/cygwin/>
List-Help:	<mailto:cygwin-help AT sourceware DOT cygnus DOT com>,
	<http://sourceware.cygnus.com/ml/#faqs>
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
From:	Sigbjorn Finne <sof AT dcs DOT gla DOT ac DOT uk>
To:	paul-ml AT is DOT lg DOT ua
Cc:	cygwin AT sourceware DOT cygnus DOT com
Subject:	Re: dlltool & memory hoggage
Date:	Fri, 6 Aug 1999 10:41:11 +0100 (BST)
Message-Id:	<14250.44472.2686.445917@hawaii>
In-Reply-To:	<7708.990805@is.lg.ua>
References:	<14248 DOT 37926 DOT 416595 DOT 443625 AT hawaii> <7708 DOT 990805 AT is DOT lg DOT ua>
X-Mailer:	VM 6.64 under Emacs 19.34.1
MIME-Version:	1.0

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 cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -