Re: reducing ld's memory footprint (19 minutes of linking)
Re: reducing ld's memory footprint (19 minutes of linking)
- Subject: Re: reducing ld's memory footprint (19 minutes of linking)
- From: Andrew Kimpton <email@hidden>
- Date: Wed, 10 Aug 2005 09:37:45 -0700
On Aug 10, 2005, at 12:19 AM, Stefan Werner wrote:
Date: Tue, 9 Aug 2005 11:54:04 -0400
From: Roy Lovejoy <email@hidden>
Subject: Re: reducing ld's memory footprint (19 minutes of linking)
as one of many engineers mandatorily migrating to XCode, (after 13+
years of CodeWarrior), I would like to say it would be nice if Apple
engineers and managers would pay attention to these REAL WORLD
benchmarks and try to _make_an_attempt_ at getting close to the
productive development environment we are used to on this platform..
Yes please. As it looks like, Xcode will soon be the only available
IDE for native Mac OS development (until someone writes a plugin
for Eclipse, I hope). It is definitely a step forward from
ProjectBuilder, but for those of us that come from CodeWarrior,
it's a huge step back in terms of performance. Xcode is nice for
creating a small Cocoa app from scratch, but it's having a hard
time dealing with large C++ projects.
Perhaps it's stating the obvious - but in this case the problem is
not with XCode but rather with the gnu tools the XCode uses.
Switching to a Makefile and using emacs for example won't necessarily
fix this problem at all.
As I recall (from an inadequately caffeinated memory) gcc and the gnu
linker have very little redundant symbol elimination. So if you have
10 source files each with 10 references to an external symbol in one
each of the other source files instead of having just 10 instances of
symbol information (one for each item) there will be 100 since each
unit will contain its requirements and there will be duplication.
This leads to very large files, and very large memory requirements as
the linker draws in all this information, which of course leads to
the slow link times. It also increases load times and symbol lookup
times in gdb.
I believe this issue is also not constrained to purely the PowerPC
platform or Apple's gnu tool branch but is also present on other
platforms. I certainly recall working on porting a large application
to BeOS (intel) some years ago when we were using gcc 2.x. The non-
debug build was 20-30MB of executable however the debug build with
symbols was over 2.5 Gbytes ! And link times were in excess of 30
minutes - needless to say we didn't bother to do many debug builds
like that and had to resort to cruder debugging techniques.
I had hoped that this problem has been reduced in subsequent gcc
versions but perhaps not enough yet.
Andrew 8-)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden