• 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: Process (Xcode): 68 leaks for 3312 total leaked bytes.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Process (Xcode): 68 leaks for 3312 total leaked bytes.


  • Subject: Re: Process (Xcode): 68 leaks for 3312 total leaked bytes.
  • From: Bill Bumgarner <email@hidden>
  • Date: Mon, 10 Nov 2008 00:03:33 -0800

On Nov 9, 2008, at 9:40 PM, Tom Bernard wrote:
True that Xcode is a GUI over gcc etc. I am now motivated to generate a
really long compile task to run leaks on gcc. Is there a better way to do
this with a UNIX script? And are gcc, the compiler and linker also garbage
collected?

Sort of. GCC implements its own memory management scheme internally. It is sort of garbage collected, but not anything like the Objective-C collector. GCC and the linker are both designed to be run once and then quit. In this situation, leaks are largely irrelevant beyond keeping the working set small during operation.


From your original message:
Process 192: 140682 nodes malloced for 10482 KB
Process 192: 68 leaks for 3312 total leaked bytes.

First, as others have noted, Xcode is a GC'd apps and leaks doesn't really work against such apps without very carefully controlling the state of the app (which isn't possible at startup). As well, there are a handful of blocks that are allocated during app startup for whom their pointers will effectively be lost to leaks -- stuck off in thread metadata, munged a bit so leaks no longer sees them, or otherwise stored in a way that leaks doesn't see it.


In any case, 3K leaked at startup -- some [often most] of which isn't really leaks -- is pretty close to irrelevant. It is small, only happens once, and is extremely unlikely to contribute to heap fragmentation.

The leaks that matter -- the ones that kill performance -- are leaks during repeated operations. For example, if Xcode were to leak 4k (one page) of memory every time a file is compiled, a file is opened/ closed, or a search is performed, it will definitely be a real drag on performance over time. Beyond consuming memory, such leaks often lead to heap fragmentation which causes general VM bloat.

b.bum

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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: Process (Xcode): 68 leaks for 3312 total leaked bytes.
      • From: Tom Bernard <email@hidden>
References: 
 >Re: Process (Xcode): 68 leaks for 3312 total leaked bytes. (From: Tom Bernard <email@hidden>)

  • Prev by Date: Re: Process (Xcode): 68 leaks for 3312 total leaked bytes.
  • Next by Date: Re: Process (Xcode): 68 leaks for 3312 total leaked bytes.
  • Previous by thread: Re: Process (Xcode): 68 leaks for 3312 total leaked bytes.
  • Next by thread: Re: Process (Xcode): 68 leaks for 3312 total leaked bytes.
  • Index(es):
    • Date
    • Thread