Theocacao: 2D Graphics and Garbage Collection in Leopard

2D Graphics and Garbage Collection in Leopard

The 2D Graphics Release Notes for Leopard have a rather important warning label for applications using garbage collection.

The Core Graphics APIs (Quartz 2D) see an approximately 25% reduction in drawing performance for applications compiled to use garbage collection. For that reason, enabling garbage collection is not recommended for applications making heavy use of 2D drawing.

There is a known issue with garbage-collected applications using Core Image to process frames from Core Video; the frame memory does not get collected, and the process eventually runs out of address space. If your application processes video frames using Core Image, enabling garbage collection is not recommended.

It's possible the 25% statistic errs on the side of being conservative. In other words, it may be much less in practice. Still, it's worth knowing about. Also, probably only matters for apps doing a lot of custom drawing.

2D Graphics and Garbage Collection in Leopard
Posted Nov 6, 2007 — 13 comments below

Rosyna — Nov 06, 07 5015

the frame memory does not get collected, and the process eventually runs out of address space.

That to me seems like a much more serious issue. Especially as it may also cause performance degradation.

And, of course, it could be much more than 25%. That's the problem with averages.

Eric Wing — Nov 06, 07 5016

Awhile back, I mucked around with the "Cocoa Slides" demo from WWDC, which demonstrates the use of Core Animation. The last part of the demo, they layer in a Quartz Composer composition. I changed some things around to enable Garbage Collection. The combination of garbage collection + layers + Quartz Composer absolutely killed performance. I think it was a lot worse than 25%.

It also led to memory leaks and crashing, but I think they fixed those bugs at least. (I filed two bugs, one on the crash, the other on the performance. They mixed up the two and combined them into one and closed both when the crash was fixed. I had to force them to reopen the performance bug.)

Blain — Nov 07, 07 5019

So is this a design or implementation issue? That is, is it just a memory leak, or does the delayed collection mean that the cache is defeated by the frames constantly going forward in memory, causing the performance hit?

Also, is there a command to the garbage collector of "I know that this is garbage. Collect it early."?

Andre — Nov 08, 07 5027

Thats unforgivable... looks like someone will be waiting for 10.5xx... -25% ..........

Blain — Nov 08, 07 5033

Thats unforgivable... looks like someone will be waiting for 10.5xx

Definitely. Because garbage collection in cocoa is so much faster in 10.4...

Shawn Erickson — Nov 08, 07 5034

@Andre developers have to opt-in to use GC. One would assume they would validate that a GC version of their application performs as they expect (just like with any other new OS service).

@Blain review the developer docs on GC. They outline ways to hint the collector however I don't recall one about specifying a specific object (sorry to busy to dig up links).

lance — Nov 08, 07 5037

... developers that use GC in obj-c also eat keish. Seriously, GC is overrated and its overuse is a design flaw. Its handy for object graphs with huge unspecified circular references and complex interrelationships though.

Scott Stevenson — Nov 08, 07 5040

@ lance: developers that use GC in obj-c also eat keish. Seriously, GC is overrated

I disagree. Anything we can do to make software crash less is a win for the user. It's not about taking the easy way out, it's letting the computer handle its own business whenever possible.

Blain — Nov 09, 07 5046

But, but, but, I like quiche. I also can play low on C, even dabble in assembler. So there. I've been kind of avoiding getting into reading the details until I can, since my current dev system is still at 10.4

That said, GC is one of those things like KVC/KVO/bindings. They're times where KVC is a huge speed hit and a major lose, especially with unintended consequences and almost circular updates. And it might make things slower since you have to do all sorts of redirections and notifications. But it really helps in prototyping, and in many cases, there's not a real need for speed, so it works. Ever since the algorithm was explained at a Cocoaheads, I've really warmed up to the idea.

Ben — Nov 28, 07 5140

I agree with Rosyna, I find it odd you presented the performance issue as primary and the horrendous game-ending memory leak as a footnote. I haven't moved to Leopard yet, but can't you do a GC project and still choose to manually memory-manage specific objects? I thought I had read that you could. Couldn't Apple just require manual memory mangement for CoreImage entities (for now)?

Ben — Nov 29, 07 5142

Scott Stevenson — Nov 29, 07 5144

@Ben: I find it odd you presented the performance issue as primary and the horrendous game-ending memory leak as a footnote.

It's a good point, but I guess I see Core Video as relatively specialized and already working in very performance-sensitive areas. Using CoreGraphics APIs is far more common, even in many simple apps. But stepping back, I see what you mean.

I haven't moved to Leopard yet, but can't you do a GC project and still choose to manually memory-manage specific objects?

Not really. You can set object-specific parameters for the collector, but they're all still garbage collected. The retain, release and autorelease methods become no-ops (for all frameworks) when garbage collection is on. CF-style objects have different rules, though.

Philip Bussmann — Feb 02, 10 7323

If your application processes video frames using Core Image, enabling garbage collection is not recommended.

Is this still true for Snow Leopard, or did this get fixed in 10.6.x?

Comments Feed