I'm not going to spend the time to give a rundown of using Instruments.app; there are plenty of places that one can get instruction online, and the application is fairly straightforward to use.
Instead, I wish to remind people how useful this can be, or give a head's up to people that aren't in the habit of using it.
It is useful to be able to monitor for leaks while you're manipulating a quartz composition file (this statement feels overwhelmingly obvious!). It can also be very informative to see where things are getting allocated. Poking around tends to reveal methods that are useful, methods that are getting called when stuff goes awry. Sometimes you can see some surprising non documented methods, so it can occasionally wind up being a boon to your programming, if you don't mind using private methods.
It can be surprising to find leaks with commonly distributed plugins, or even with a stock install. It can be difficult to peg something to a particular patch sometimes, but one can manipulate the composition while monitoring, to try to home in on the problem. There are some real "gee whiz" leaks that happen sometimes, with or without 3rd party plugins. Trial and error can help you figure out how to get rid of a leak.
For instance, today I was having NSURL and GFList leaks, that were vexing, but through trial and error, and the elimination of various patches from the main quartz composition file, I've seemingly pegged them (jury is still out, but it looks promising). Instruments.app helped me pinpoint those. It was already time consuming, but would have been ridiculously time consuming to impossible to find the problems otherwise.
It's a total pain in the butt, and even intimidating, to figure out how to work around the bugs, but at least I've managed to peg some issues that I would not have otherwise been able to. It is probable that there could be GFList, NSUrl, NSEvent, NSCFArray, CGEvent, etc., issues, even without 3rd party plugins, by the way. I've seen that as well. The QCEditor.app does seem to leak when doing certain functions, to varying levels of impact. It can really be worth making your own app to run the qtz file, and then you can have the same kind of fun time monitoring leaks with your own Xcode project, but at least you've gained a bit more control (theoretically). I say this, because, in some scenarios, just manipulating the QC Editor causes leaks. Running your composition in an app can be a good idea for that reason, even though the QuartzComposer.app (QC Editor) presents a nice face.
Quartz Composer reminds me of the Wizard of Oz sometimes; there is a man behind the curtain! When one is putting together quartz compositions, one can be pretty far removed from what's going on behind the scenes.
QC makes so many things non-obvious to the programmers that are just trying to setup a sequence of evaluation between patches. They, or hey, I, go assuming that everything is awesome, because it appears to be awesome with 10-15 minutes of runtime. I think the end users and programmers sort of have that right to assume that, but should be cautious. It's not like Photoshop, where you're just manipulating stuff, and don't really have to worry about app stability. QC presents a face that is much like "photoshop for 3d and 2d media", but I suspect it's easier to do whacked out stuff to your computer with QC, because it's programming environment, not just an app that manipulates media.
For people programming plugins/patches, they should consider seeing if anything seems to be going nuts while they use their plugin inside of QC, not just through use of it in QC, but by using Instruments.app and OpenGL Profiler where applicable. There's not always time or will for profiling I guess, and sometimes one just needs to crank something out, or maybe it doesn't even matter for some use cases? I do get that each use case, and the amount of time one can spend on things is different. (It doesn't really seem to take a ton of time though.)
If anyone has any thoughts, or is an Instruments.app/hacker guru, feel free to respond. This isn't any kind of definitive article - it's about 10 minutes of stream of consciousness, at best - a quick run through of some observations I've had that may lead others down a path of getting better end results