• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: reducing ld's memory footprint (19 minutes of linking)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: reducing ld's memory footprint (19 minutes of linking)
      • From: "Sean McBride" <email@hidden>
References: 
 >Re: reducing ld's memory footprint (19 minutes of linking) (From: Stefan Werner <email@hidden>)

  • Prev by Date: DOS pathname separators?
  • Next by Date: Re: [OT?] How does IB make DataBrowser small
  • Previous by thread: Re: reducing ld's memory footprint (19 minutes of linking)
  • Next by thread: Re: reducing ld's memory footprint (19 minutes of linking)
  • Index(es):
    • Date
    • Thread