The documentation has this to say:

Important: This method is typically of no value in debugging memory management issues. Because any number of framework objects may have retained an object in order to hold references to it, while at the same time autorelease pools may be holding any number of deferred releases on an object, it is very unlikely that you can get useful information from this method.

Makes it pretty clear that you shouldn’t be calling retainCount, but it really doesn’t illuminate exactly how useless the method is outside of a very narrow context.

So, let us count the ways:

1. The absolute retain count of an object may change at any time once an object has been passed through any system API.
2. Any subclass of any system provided class counts as “through system API”; the retain count may be impacted by implementation details.
3. The retain count never reflects whether an object is autoreleased.
4. Autorelease is a per-thread concept whereas retain counts are global; race condition derived hilarity can easily ensue.
5. The retainCount method can never return 0.
6. Some classes are implemented as singletons some of the time.
7. Some classes may internally manipulate their retain count directly (I.e. no swizzle for you!).
8. While retain/release are effectively thread safe, there is always a race between calling retainCount and having the actual retain count change in some other execution context.

Bottom line: the only time the absolute retainCount can be conclusively used for analytic purposes is if you have the backtrace of every retain and release that contributed to the current retain count’s value (there is another use case, documented at the end). If you have that, then you don’t need the retain count and, fortunately, Instruments is already generally quite adept at producing a per-object inventory of retains and releases for you (see Analyzing Data with the Allocations Instrument“.

In general, you should consider the retain count as a delta. Your code causes the retain count to increase and decrease. You don’t +alloc an object with a retain count of 1. Instead, you +alloc an object with a retain count of +1. If you want that object to go away, you need to do something — release, always and eventually — that causes the retain count to be decremented by 1.

It really is that simple.

Almost.

Concurrency — whether through threading or GCD — throws a bit of a wrench in the works (as it always does). Namely, the retain count should really be considered as a per concurrency context delta. If thread or queue A wants to do something with object X, it should hold a +1 retainCount on X for the duration of said operation. One subtle detail that will bear repeating later; an autorelease‘d object does not contribute to thread safety. That is, if thread or queue A wants to pass X to thread or queue B, there must be an explicit retain in A that is balanced by a release (or synchronization event back to A) in B.

Now, some of the enumerated claims may either seem specious at best or, certainly, not obvious as to exactly how it undermines the validity of the retain count.

1. The absolute retain count of an object may change at any time once an object has been passed through any system API.

The system is free to retain and release any object at whim and, in fact, it will often do so. An object may be shoved into a collection, it might be cached into a map somewhere by a computed key, or it might be retain‘d long enough to survive enqueueing for execution asynchronously.

As well, the object may be retain’d then autorelease’d such that the retainCount will look like it is N when it is really, effectively, N-1. If that retain/autorelease happened in a queue somewhere, the number returned may imply a greater # of strong references than truly exist.

2. Any subclass of any system provided class counts as “through system API”; the retain count may be impacted by implementation details.

This is really the same point as the first, but emphasizes that all bets truly are off once you subclass a system class. As the system’s use of concurrency during drawing grows over time, you can expect that any UI related subclassed classes will likely have their retain counts manipulated across concurrency boundaries potentially frequently.

3. The retain count never reflects whether an object is autoreleased.

When you call autorelease, not much really happens. The object is neither retain‘d nor release‘s. Instead, it is added to the current per-thread autorelease pool. The release is effectively delayed until the pool is drained or deferred to the next outermost pool if the pool is popped without draining (which can happen due to bugs or exceptions [exceptions are an indication of bugs in and of themselves in Cocoa]).

Once an object is added to an autorelease pool, there is no way to query whether or not it is in such a state. Thus, whatever retain count is currently returned may not actually reflect the effective retain found at all.

4. Autorelease is a per-thread concept whereas retain counts are global; race condition derived hilarity can easily ensue.

But it gets worse (at least, worse for the developer making the mistake of thinking retainCount is meaningful).

The retain count of an object is actually global to all contexts of concurrency. An object has one and only one retain count. While calling retain and release are concurrency safe, there is no way to express call retain and don’t let another execution context increment or decrement it until I’m done pondering the return value.

5. The retainCount method can never return 0.

When an object’s retain count transitions from 1 to 0, the object is deallocated (usually). As a result, if you retainCount on a non-nil reference, it can never return zero because doing so would require calling a method on a deallocated object which is undefined behavior.

Or, to put it more bluntly, this can never work (Yes, I had to go there):

while([bg retainCount]!=0)
{
  [bg release];
}

One might claim that if you message nil, you’ll get 0 in return. True; but no code outside of a short circuit in objc_msgSend() is executed. That is, the method isn’t returning zero, the messaging mechanism is short circuiting prior to calling the method.

6. Some classes are implemented as singletons some of the time.

Consider:

NSNumber *n = [NSNumber numberWithInt: 4];
printf("%p rc: %u\n", n, [n retainCount]);
n = [NSNumber numberWithInt: 4];
printf("%p rc: %u\n", n, [n retainCount]);
n = [NSNumber numberWithInt: 42];
printf("%p rc: %u\n", n, [n retainCount]);
n = [NSNumber numberWithInt: 42];
printf("%p rc: %u\n", n, [n retainCount]);

And the output on i386:

0x115410 rc: 2
0x115410 rc: 3
0x115950 rc: 1
0x115df0 rc: 1

Now consider x86_64:

0x483 rc: 9223372036854775807
0x483 rc: 9223372036854775807
0x2a83 rc: 9223372036854775807
0x2a83 rc: 9223372036854775807

For this particular class, the behavior is different depending on value and depending on architecture. You could expect potentially even different behavior on an iOS device. Likewise, if you were to run the 64 bit variant on Snow Leopard, it would be different yet again!

Internally, NSNumber uses singletons for a small subset of values on certain platforms. On x86_64, it uses tagged pointers (Bavarious explains tagged pointers quite well in this blog post. I should update the objc_msgSend() tour to reflect the new messenger in Lion, too) to avoid allocating anything for the object altogether.

In all cases, relying upon the retain count of an NSNumber will create a dependency on system behavior that will quite likely change in the future, breaking your program rather badly.

Many other classes within the frameworks have similar optimizations for the common cases. Likewise, because of polymorphism and/or duck typing, it is likely that a system API declared to return an instance of, say, NSString might return an instance of a seemingly unrelated class whose interface is string compatible.

7. Some classes may internally manipulate their retain count directly (I.e. no swizzle for you!).

It may be tempting to override retain, release and autorelease in existing classes using a swizzling mechanism or the like. Depending on the class, you might find that the retain count of an object is changing more than the # of calls to retain/release/autorelease might otherwise warrant!

This is because a class might choose to implement a retain count mechanism differently than the one provided by NSObject and, thus, might internally directly manipulate the retain count without going through the various methods.

Since the retainCount of an object is not an observable property (ewww… boy howdy that’d be ugly if it was), this direct manipulation is perfectly valid. However, it means that you cannot count on being able to externally modify an existing class to observe the retain count.

Nor should you need to. The system classes are designed such that they should be compatible with the Allocation Instrument’s ability to track reference count changing events, including grabbing a backtrace. If you find a class that isn’t, file a bug, please.

8. While retain/release are effectively thread safe, there is always a race between calling retainCount and having the actual retain count change in some other execution context.

Mmm… concurrency… where 1+1 can yield 3.

As was mentioned before, there is no operation via which you can query an object for its retainCount in a fashion that guarantees the retain count won’t change immediately after you retrieve the value, including potentially deallocating the object.

That is to say, there is no retain/release locking mechanism.

Thus, as soon as you retrieve the retainCount of an object, that value may be incorrect unless you can absolutely guarantee that the object is not being manipulated by any other execution context. And the only way to guarantee that is to pretty much stick to a direct subclass of NSObject (which, in and of itself, isn’t really technically correct either) and limiting manipulation of said object(s) only to threads/queues where you exactly control every aspect of interaction with said object; i.e. no system APIs for you!

The above doesn’t even consider the inherent design fragility in colluding the reference count of objects with other functionality. The classic “scarce resource recollection” problem of GC very much exists in a manual retain-release realm, for example.

So, when is retainCount useful?

I have encountered a handful of cases where the retain count of an object was used internally as a sort of “mode of use” indicator. That is, if an object’s retainCount is 2 when -release is invoked, the framework will assume, say, that the object is transitioning from “in use” to “available for quick reuse”. Typically, this is a sort of allocation cache or instance cache. Often, this is done because instantiation of the object is fairly expensive and, thus, the goal is to create a pool of available objects that can quickly be reused.

While a valid use, it tends to be fragile and tends to make crashes more difficult to analyze. Namely, one stray release or autorelease and you are likely to have a crash in the caching mechanism. At least with a crash in in NSAutoreleasePool, it is immediately obvious where things went off the rails.

A far less fragile solution is to encapsulate the expensive bits within a second container within the object. That container can be “checked in” and “checked out” by the object as a normal part of allocation/deallocation. This decouples cache magic from retain count.

The best possible solution to all of this is to move to ARC! Automatic Reference Counting, by and large, works incredibly well for a technology that is so new. The compiler and runtime teams have taken a very conservative approach that makes this so. Basically, if the compiler can’t reason through a piece of code to determine with total certainty exactly what the retain/release behavior should be, it generates an error instead.

It works quite well and many of Apple’s newer releases feature big chunks of code that are ARC’d.

If you can’t go ARC yet for whatever reasons, then dealing with manual retain-release is really quite simple and covered well in the documentation. The key is to ignore the retain count as a value and treat it purely as something you increase and decrease; you must balance every increase with a decrease if you want a particular object to be deallocated or over-released in the case of too many decrements.

And I noticed something odd. As expected, the RPRVT of Hex Fiend was growing on each cmd-n. However, the RPRVT was not decreasing the same amount every time I hit cmd-w.

That ain’t right. Or it might be. Beyond evidence that a memory use problem may exist, top is a horrible tool for determining if a problem is real or what the actual problem might be.

In this case, the issue looks like a simple memory leak. Hex Fiend is allocating and retaining some set of objects, but not releasing them. The easiest first step is to use the leaks command line tool:

% leaks "Hex Fiend"
leaks Report Version:  2.0
Process:         Hex Fiend [3435]
Path:            /Volumes/Data/Applications/Hex Fiend.app/Contents/MacOS/Hex Fiend
Load Address:    0x100000000
Identifier:      com.ridiculousfish.HexFiend
Version:         2.0.0 (200)
Code Type:       X86-64 (Native)
Parent Process:  launchd [122]
Date/Time:       2010-10-16 20:47:09.935 -0700
OS Version:      Mac OS X 10.6.4
Report Version:  7
Process 3435: 22980 nodes malloced for 2600 KB
Process 3435: 0 leaks for 0 total leaked bytes.

OK; whatever the problem is, it isn’t “leaked” memory in the traditional definition of “leaked memory”.

That is, whatever memory is being allocated and never released is still being referenced somewhere. Maybe a circular retain. Maybe something that has a weak reference from the rest of the App’s object graph such that leaks can’t detect.

In other words, this isn’t just a simple memory leak and it will require more advanced tools to fix.

Fortunately, the Allocations Instrument provides exactly the tool we need. It is called Heapshot Analysis and it is brutally effective at deducing these kinds of problems.

To use:

• Launch Instruments and select the Allocations template under the Memory category.
• Target the application you want to analyze. It can already be running or you can launch it from Instruments. As well, you can launch it from Xcode via the Run With Performance Tools menu.
• (10) Do something in the application where you return to the starting state. For Hex Fiend, this particular case is as simple as creating a new document and then closing it. For an optimal application, this activity should effectively cause no memory growth (or very little).
• In the Allocations Instrument, press the Mark Heap button
• Goto 10 (and repeat 5 or 6 times).

I ended up with the data as seen to the left. Each “Heapshot” iteration represents opening, then closing, an untitled window with no data in it.

The “Heap Growth” and “Still Alive” columns provide a summation of all of the objects in that heapshot that still exist in all subsequent samplings of the heap. That is, in Heapshot 3, there were 36.08K of allocations spread across 260 allocation events that continued to exist throughout the rest of the run.

Specifically: the values in those columns represent permanent heap growth.

When creating, then closing, an untitled document there should be, ideally, no heap growth. That there is ~35K per document of permanent heap growth indicates that a leak does exist (regardless of what leaks said above).

Note that as you continue to iterate, you might see the values of previous Heapshot samples decrease. That is because objects allocated in that sample — at that heap mark — have been released. That is, every single object listed in that table — all ~25,000 or so in that screenshot alone — are very much in memory, using resources, and sticking around.

Instruments lets us dive deeper.

Not only can we expand any given Heapshot iteration to see the inventory of permanent objects allocated in that iteration, but we can dive all the way down to the individual allocations and see a backtrace of exactly where it was allocated.

Looking at many of the allocations, they all seem to be during either the initialize of an instance of MyDocument or during loading of the user interface related with the same.

No surprises there; the inventory of objects is clearly related to the document.

What is surprising, though, is that an instance of MyDocument doesn’t show up on that list! It looks like the instance of MyDocument is correctly being deallocated on window close, but much of the user interface related to the document is not!

While we clearly have enough evidence to suspect MyDocument as being the source of the issue, we can confirm this further within Instruments.

Turn on Record reference counts in the Allocations instrument. When the app isn’t running, hit the little (i) in the Allocations track in Instruments and click the check box. Then run the application and do the same set of samples (or turn this on from the beginning if you didn’t forget like I did).

Now, when you click through any allocation, you’ll see a list of events that includes the point of allocation and all subsequent retain/release events. Clicking through many of the random objects in any given Heapshot sample shows two things. First, all of the objects ended with a retain count of 1 — not 2, not 5, but 1 — this indicates that whatever the problem is, it is likely pretty consistent and we can fix it once and be done with it. Secondly, the non-UI related objects like DataInspector or NSBigMutableString have very few events and they largely come from [MyDocument -init], further confirming our suspicions.

Now it is time to turn to the source.

Which I need to download; all of the above was done against the app without the source.

OK — got it — now — start with MyDocument‘s init method (which doesn’t do the self = [super init]; if (self) {...} return self; dance. Boo.) and compare it to dealloc

The init method looks fairly straightforward; allocate a bunch of stuff, glue it together, return self:

- init {
    [super init];
    lineCountingRepresenter = [[HFLineCountingRepresenter alloc] init];
    hexRepresenter = [[HFHexTextRepresenter alloc] init];
    asciiRepresenter = [[HFStringEncodingTextRepresenter alloc] init];
    scrollRepresenter = [[HFVerticalScrollerRepresenter alloc] init];
    layoutRepresenter = [[HFLayoutRepresenter alloc] init];
    statusBarRepresenter = [[HFStatusBarRepresenter alloc] init];
    dataInspectorRepresenter = [[DataInspectorRepresenter alloc] init];
    ... etc ...

As a matter of fact, pretty much all of those representers are showing up as still in memory per each Heapshot mark!

And, diving into the individual retain/releases, we see that some of the representers are connected to other representers. So, if anyone of those representers is sticking around, it might likely keep others alive with it, too! Or it could be a circular retain issue. But, before we start trying to deduce hard problems, we should exhaust the simple causes first and look at the dealloc method.

The first thing that jumps out at me is that the dealloc method is trying to do something clever. Instead of line-by-line calling release on every object allocated in init, it does:

    [[self representers] makeObjectsPerformSelector:@selector(release)];

OK. So, what does representers look like?

- (NSArray *)representers {
    return [NSArray arrayWithObjects:lineCountingRepresenter, hexRepresenter,
               asciiRepresenter, scrollRepresenter,
               dataInspectorRepresenter, statusBarRepresenter, nil];
}

Waitaminute there…. comparing that array’s contents to the items allocated in init, we see that the layoutRepresenter is missing. Nor is it explicitly released anywhere else in dealloc!

That’d be the leak right there! And leaks won’t detect it because there are enough non-retained relationships that the objects look like they are still reachable from the application’s core object graph!

The naive fix would be to add layoutRepresenter to the array returned by -representers. However, the layoutRepresenter seems to be kinda special in its role and, frankly, I really hate tricky dealloc games like making an array of objects perform release.

So, I replaced the performSelector: in dealloc with:

    [lineCountingRepresenter release];
    [hexRepresenter release];
    [asciiRepresenter release];
    [scrollRepresenter release];
    [layoutRepresenter release];
    [statusBarRepresenter release];
    [dataInspectorRepresenter release];

Running the heapshot analysis again shows that the # of permanent allocations per iteration has dropped from ~250 to a consistent 8. Vast improvement, but still not perfect.

Looking at the remaining allocations, every single one is allocated in drawLineNumbersWithClipStringDrawing.

In particular, it is the drawing call here that is the source of the remaining leaks (except one):

	    NSString *string = [[NSString alloc] initWithBytesNoCopy:buff
						length:newStringLength
						encoding:NSASCIIStringEncoding freeWhenDone:NO];
            [string drawInRect:textRect withAttributes:textAttributes];
            [string release];

But, wait, how can that be? Well, it could be a bug in the AppKit. Or it could be some kind of a weird cache. As a matter of fact, if you create about 30 documents in Hex Fiend, then close them all, you will see the previous heap marks drop to 7 objects remaining. So, clearly, there is some kind of a size limited cache that is eventually being pruned. Obviously, not a very efficient cache if it is filling with copies of the same objects. I like to call these kinds of caches write only caches. All the benefits of high memory use combined with all the efficiencies of a 100% cache miss rate! FTW!

The one other leak, though, is that the dealloc method in HFLineCountingView is not releasing the textContainer. First, I’ll fix that and re-measure. Done. That removes one object from each Heapshot iteration.

OK — so, looking at the remaining objects, we have a set of objects that look an awful lot like a set of attributes for text; a paragraph style, color, etc…

Sure enough, textAttributes is not being released in dealloc.

So, where do we stand?

See for yourself!

Not bad! No leaks on many iterations. That 1 4KB malloc seen in some iterations is likely some internal cache in the AppKit. That it doesn’t always appear and eventually goes away indicates that it is both behaving correctly and can be ignored.

The next step would be to do the same kind of testing, only with documents that contain actual data. Then do the testing after making a set of edits and undoing them.

Heapshot analysis has proven to be an incredibly effective tool for identifying and fixing memory use issues in applications. The above style of use where you pick a task that should return state back to the same as it was when you started is the most effective form of this analysis.

However, this same approach can be used for applications that build up or change state over time (think Mail, which has new messages coming in all the time or an application with an accretion of logs or undo state).

Fire up your application under Instruments and periodically hit “Mark Heap” when your app is in a reasonable state. The more Heap Shots you capture, the easier it is to analyze. Look at any given iteration and ask yourself Why do these objects created way back when still exist in memory and is their use of resources justified?. The follow up question is What can I do to make the permanent memory accretion smaller?.

So, I moved ‘em over.

You can find them in the PyObjC subversion repository.

These aren’t just templates, though. See the README.txt.

As it implies, the project-tool.py script is used to effectively convert between Xcode templates and buildable projects. That is, you can create a project that builds/runs like a regular Xcode project, and then easily turn it into a template with the invocation of a simple command line like this:

project-tool.py -k -v --template Cocoa-Python\ Document-based\ Application/CocoaDocApp.xcodeproj/TemplateInfo.plist \
    Cocoa-Python\ Document-based\ Application/ \
    ~/Library/Application\ Support/Developer/Shared/Xcode/Project\ Templates/AA\ Testing/Cocoa-Python\ Document-based\ Application

Or, specifically:

./project-tool --help
Usage: project-tool.py [options]  

    Copies tree of templates or projects from  to .
    Before copying, it cleans up  by removing various bits of garbage.
    After copying, it transforms  by replacing strings with their Xcode
    template counterparts.

    The reverse flag can be used to reverse this process; turning an Xcode
    template into a working project.

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -v, --verbose         verbose
  -k, --kill-dest       erase  (no warning)
  -r, --reverse         reverse transformation (template -> editable project)
  -w, --working         try to make destination into a working project
  -n, --nib             rewrite NIB files to 10.5 text-only format
  -t TEMPLATEFILE, --template=TEMPLATEFILE
                        path to TemplateInfo.plist that should be used during
                        conversion

Nothing remotely Python specific about it. And, as some have noticed, the PyObjC Cocoa templates leverage the new Interface Builder file format (xib) such that all kinds of substitutions happen in the templated interfaces, too. As in: No more MyDocument ever again.

Beyond fixing a boatload of bugs and numerous performance improvements, Xcode 2.3 adds DWARF as a native symbol format. DWARF yields a significantly higher fidelity debugging experience, especially for complex C++ code, while also reducing the memory requirements of the linker.

Full release notes available on Apple’s developer tools web site.

Xcode 2.3 also includes a new distributed build subsystem called Dedicated Network Builds. The preferences pane is a bit fragile — don’t poke at it too hard — but the underlying technology is some neat stuff.

While DistCC remains as the solution of choice for ad-hoc builds on small networks, Dedicated Network Builds [DNB] focuses on accelerating large projects where a farm of machines can be dedicated as builders. In particular, DNB shines with large C++ projects.

Behind the scenes, DNB distributes compilation jobs from your local machine — the recruiter — to the builder machines — the volunteers — using a set of daemons to connect everything together. On the recruiter, a daemon monitors the filesystem to ensure that changes made to the filesystem will cause the remote volunteer caches to be invalidated in an appropriately minimalist fashion.

The volunteers execute the jobs against a mirrored copy of the recruiter’s local filesystem, source, headers, compiler and all. As such, the only dependency between your local machine and the builders is that they are both the same architecture (ppc or i386) and they are running very close to the same version of Mac OS X (i.e. 10.4.5 will be compatible with 10.4.6, but not 10.3.9).

A great deal of effort went into ensuring that cache management wouldn’t swamp the recruiter’s network connection. There is still a hefty cache warmup hit, but the volunteers have the ability to resolve cache misses amongst themselves as well as resolving cache misses against their own local filesystem, when possible.

As one can imagine, there is considerably more to this technology than is described above.

Go read this article about unit testing and code coverage. Specifically, Chris gives detailed instructions on how to integrate gcov based code coverage into Xcode while also leveraging Xcode’s support for unit testing.

Excellent article. Thanks for writing it, Chris. I hope you don’t mind if I file a couple of bugs against Xcode to remind us to integrate something like what you have done sometime in the future.

One very important feature of the advanced breakpoints found within Xcode is the ability to cause something to happen in the debugger — play a sound, print some data, run some AppleScript or invoke a shell script — without interrupting the application being debugged beyond stopping it briefly to take whatever action is specified in the breakpoint.

For debugging stuff like drag-n-drop, mouse tracking, and other human-computer-interaction related functionality, being able to break, take action, and continue the application without de-activating the application or otherwise messing with the context of event processing is absolutely critical.

In modern applications, the challenges of debugging are often not about which line of code is broken, but a matter of figuring out which of the 100,000 executions of a particular line of code is broken. Worse, the line of code is generally going to be invoked along one of many paths, often further convoluted by the code’s presence within a class hierarchy such that invocation is determined by state or customization applied by subclasses.

printf style debugging is often derided as an amateurish approach to figuring out what is going on. And it does suck. But it is often the only way to really figure out what is going on.

Until now. I’m finding that I will configure a breakpoint to log-and-continue. Once I figure out what offensive value is at the root of a problem, I can easily configure the breakpoint to no longer continue and to only stop when that value is present.

End result; no more stop/print/continue by hand with the debugger constantly futzing with the event processing context of the application.

Very, very useful.

The list with very brief descriptions. Click through for more information.

2373705: Senior Embedded Systems Engineer Help to improve support for iPod development within the Xcode tool-chain.

2374115: Performance Analysis Tools Engineer Improve the integration and capabilities of the performance analysis tools included with Xcode.

2374098: Embedded Systems Performance Engineer Embedded systems (iPod) focused improvements to the performance analysis tools included with Xcode.

2375392: Distributed Build Engineer Help to improve the distributed build feature within Xcode.

2374092: Build Systems Engineer Focused on improving the build system within Xcode. This is not about building Xcode itself, but about refining the code that is run when a developer hits the Build button while running Xcode.

2371488: Xcode Engineer — Xcode UI The Xcode team is seeking an experienced engineer with excellent end user application human interface design skills to conceive, design and develop future enhancements to Xcode and its supporting tools.

The following isn’t with the Xcode team, but may be of interest to folks interest in contributing to development tools.

2371718: Interface Builder Engineer Help to improve and extend Interface Builder.

It includes:

• Initial port to Mac OS X for Intel
• Xcode 2.1 compatibility
• Support for SenTestingKit and SecurityFoundation frameworks
• Complete wrappers for DiscRecording framework
• … a handful of other bug fixes …

Full details can be found in the NEWS file.

These references are both extremely powerful and quite easy to configure incorrectly. Any resource reference can be either via a relative or absolute path. If relative, it can be relative to one of several locations including the project, the enclosing group, or the build directory.

Now, Xcode also has a very useful feature that allows you to specify a location into which all build products and intermediate products will be written. First and foremost, this will eliminate the noise of the build directory from your workarea. No more “? build” noise from CVS or Subversion. If you point it to the fastest hard drive on your system, you will also gain the advantage of all the intermediate and final products being written to and read from that fast device. If you have a boatload of RAM, create a RAM drive and eliminate a huge chunk of disk I/O from the build process. If using FileVault, moving the build directories will eliminate the overhead of encrypting the files created during the build of the project (with the obvious security sacrifice).

Just make sure you get the resource references correct. In particular, If you have multiple targets and then have a copy files build phase that copies those targets’ products into the product of some other target, make sure you use a build directory relative reference.

A project relative reference will work, but only on your system and only if your build directory never moves relative to your project directory.

And that is the real challenge to resource references. Misconfigured references will work on your machine the first time you set them, but will fail if used in an environment without exactly the same set of paths.

To help minimize the problem:

• Use Xcode’s preferences to set the intermediate and final build product directories to some place other than the project. Don’t use the same path. I have often set the path to /tmp/build-bbum/intermediate and /tmp/build-bbum/products respectively. This also guarantees that the projects will be rebuilt after any reboot. Occasional clean rebuilds often seem to clean up weird issues.
• Create a second user account on your system and use Fast User Switching to occasionally bop over, update a workarea and build the project. This will also rapidly pick up revision control problems, such as forgetting to add a resource to the repository.
• Better yet, keep a workarea on a second machine or have a friend do an update and make sure things still build.

This came up because I had been playing with Growl and had checked out the source because I wanted to fix a few bugs. The CopyFiles build phase in the GrowlHelperApp were project relative, but referred to build products, thus assuming that the build directory is always in the same place relative to the project.

The book is effectively the course materials for the Big Nerd Ranch course of the same name.

Co-authored by Mark Dalrymple and Aaron Hillegass, the book covers many advanced topics in the same clear/concise manner as Aaron’s original Cocoa programming book.

The book is focused on relatively advanced topics such as memory management, the run loop, multiple processes, rendezvous and many other topics. Instead of focusing on the high level details, each topic is investigated from the perspective of documenting the technical details– often non-obvious– through the use of examples, diagrams and discussions.

Two bits that immediately grabbed my attention–and are examples of the approach found in the rest of the book– where the discussion of malloc() behavior and the discussion of the run loop.

In the case of malloc(), the book precisely discusses the fact that malloc() does not necessarily return the number of bytes that you think it does — it often returns more based on certain internal optimizations. The end result is that quite a number of memory size reduction related optimizations are a complete waste of time! Instead, you might be able to consume a few extra bytes by not compressing the data structures and gain raw performance in terms of the # of CPU cycles needed to access the data.

The discussion of the run loop was also of great interest. It clearly diagrams the run loop and the exact point during the run loop — both CFRunLoop and NSRunLoop — that the various events and timers will be handled.

Excellent, excellent stuff.

The $100 price tag is a bit higher than most developer books, but the content is of an advanced and highly refined nature. $100 is a heck of a lot cheaper than $3,500 — the entrance fee to the class for which the book was written.

Big Nerd Ranch has also made a set of resources and forums available online.