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
Date: Thu, 5 Aug 1999 17:00:38 +0300
From: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
X-Mailer: The Bat! (v1.32) S/N 42477D76
Reply-To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
X-Priority: 3 (Normal)
Message-ID: <7708.990805@is.lg.ua>
To: Sigbjorn Finne <sof AT dcs DOT gla DOT ac DOT uk>
CC: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: dlltool & memory hoggage
In-reply-To: <14248.37926.416595.443625@hawaii>
References: <14248 DOT 37926 DOT 416595 DOT 443625 AT hawaii>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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