Reusing a CGContext causing odd performance losses

Question

My class is rendering images offscreen. I thought reusing the CGContext instead of creating the same context again and again for every image would be a good thing. I set a member variable _imageContext so I would only have to create a new context if _imageContext is nil like so:

if(!_imageContext)
    _imageContext = [self contextOfSize:imageSize];

instead of:

CGContextRef imageContext = [self contextOfSize:imageSize];

Of course I do not release the CGContext anymore.

These are the only changes I made, turns out that reusing the context slowed down rendering from about 10ms to 60ms. Have I missed something? Do I have to clear the context or something before drawing into it again? Or is it the correct way to recreate the context for each image?

EDIT

Found the weirdest connection..

While I was searching for the reason why the app's memory is incredibly increasing when the app starts rendering the images, I found the problem was where I set the rendered image to an NSImageView.

imageView.image = nil;
imageView.image = [[NSImage alloc] initWithCGImage:_imageRef size:size];

It looks like ARC is not releasing the previous NSImage. First way to avoid that was to draw the new image into the old one.

[imageView.image lockFocus];
[[[NSImage alloc] initWithCGImage:_imageRef size:size] drawInRect:NSMakeRect(0, 0, size.width, size.height) fromRect:NSZeroRect operation:NSCompositeSourceOver fraction:1.0];
[imageView.image unlockFocus];
[imageView setNeedsDisplay];

The memory problem was gone and what happened to the CGContext-reuse problem? Not reusing the context now takes 20ms instead of 10ms - of course drawing into an image takes longer than just setting it. Reusing the context also takes 20ms instead of 60ms. But why? I don't see that there could be any connection, but I can reproduce the old state where reusing takes more time just by setting the NSImageView's image instead of drawing it.

One context = one image, since the context holds information about the rasterized (rendered) image. — , Dec 28 '12 at 15:38
After one image is rasterized it is saved into a file so the context is available for the next image and the context's bitmap data will be overwritten. But why would drawing into a reused context take more time than creating a new context (which also has to allocate the bitmap data) and then draw into it? — Enie, Dec 28 '12 at 16:23
When you profiled your application in Instruments, what did you find? — Peter Hosey, Dec 28 '12 at 21:55
@PeterHosey Reusing `CGContext`: 7061ms CGContextDrawImage, 557ms dispatch_apply, 75ms NSLog, 38ms CGBitmapContextCreateImage. Creating new context 1225ms CGContextDrawImage, 664ms dispatch_apply, 57ms NSLog, 28ms CFRelease, 21ms CGBitmapContextCreateImage. So reusing causes the `CGContextDrawImage` function to be six times slower, while releasing the context only takes an insignificantly short amount of time. (I guess `CFRelease` actually is `CGContextRelease`) — Enie, Dec 29 '12 at 00:23
Is the image/context size constant? That is, are you sometimes scaling the image (drawing the image into a rectangle that is not the same size as the image) when you're reusing the context? — Peter Hosey, Dec 29 '12 at 18:54
@PeterHosey The context is always the same size, same color profile, same bit size and order. The images that are drawn into the context could theoretically vary in size, but they would be rescaled to the context size. Though the image set I used has the same size as the context, so rescaling is not an issue. Also the images I use are the outcome of another app which means that I know they are all 8bit gray images, so the conversion to the context's RGBA8 is always the same. — Enie, Dec 30 '12 at 10:24
Have you tried calling `CGContextClearRect` in between reuses of the CGContext? How does that affect performance profile? — Ryan Artecona, Dec 30 '12 at 23:36
Yes, reusing context with or without `CGContextClearRect` takes six times more time. — Enie, Dec 31 '12 at 15:22
In the Apple docs for [`CGBitmapContextCreateImage`](https://developer.apple.com/library/mac/#documentation/graphicsimaging/reference/CGBitmapContext/Reference/reference.html), it says the actual bit-copying operation doesn't happen until more drawing is done on the original context. Could it be that `CGContextDrawImage` is implicitly incurring the cost of this bit-copying? What happens when you release the created image right away, and don't set it in your `imageView`? — Ryan Artecona, Jan 01 '13 at 03:38

ipmcc · Accepted Answer · 2013-01-02T19:52:07.437

I investigated this, and I observe the same slowdown. Looking with Instruments set to sample kernel calls as well as userland calls shows the culprit. @RyanArtecona's comment was on the right track. I focused Instruments in on the bottom most userland call CGSColorMaskCopyARGB8888_sse in two test runs (one reusing contexts, the other making a new one every time), and then inverted the resulting call tree. In the case where the context is not reused, I see that the heaviest kernel trace is:

Running Time    Self            Symbol Name
668.0ms   32.3% 668.0           __bzero
668.0ms   32.3% 0.0              vm_fault
668.0ms   32.3% 0.0               user_trap
668.0ms   32.3% 0.0                CGSColorMaskCopyARGB8888_sse

This is the kernel zeroing out pages of memory that are being faulted in by virtue of CGSColorMaskCopyARGB8888_sse accessing them. What this means is that the CGContext maps VM pages to back the bitmap context but the kernel doesn't actually do the work associated with that operation until someone actually accesses that memory. The actual mapping/fault happens on first access.

Now let's look at the heaviest kernel trace when we DO reuse the context:

Running Time            Self            Symbol Name
1327.0ms   35.0%        1327.0          bcopy
1327.0ms   35.0%        0.0              user_trap
1327.0ms   35.0%        0.0               CGSColorMaskCopyARGB8888_sse

This is the kernel copying pages. My money would be on this being the underlying copy-on-write mechanism that delivers the behavior @RyanArtecona was talking about in his comment:

In the Apple docs for CGBitmapContextCreateImage, it says the actual bit-copying operation doesn't happen until more drawing is done on the original context.

In the contrived case I used to test, the non-reuse case took 3392ms to execute and the reuse case took 4693ms (significantly slower). Considering just the single heaviest trace from each case, the kernel trace indicates that we spend 668.0ms zero filling new pages on the first access, and 1327.0ms writing into the copy-on-write pages on the first write after the image gets a reference to those pages. This is a difference of 659ms. This one difference alone accounts for ~50% of the gap between the two cases.

So, to distill it down a little, the non-reused context is faster because when you create the context it knows the pages are empty, and there's no one else with a reference to those pages to force them to be copied when you write to them. When you reuse the context, the pages are referenced by someone else (the image you created) and must be copied on the first write, so as to preserve the state of the image when the state of the context changes.

You could further explore what's going on here by looking at the virtual memory map of the process as you step through in the debugger. vmmap is the helpful tool for that.

Practically speaking, you should probably just create a new CGContext every time.

score 8 · Answer 2 · answered Jan 02 '13 at 20:32

To complement @ipmcc's excellent and thorough answer, here is an instructional overview.

In the Apple docs for CGBitmapContextCreateImage it is stated:

The CGImage object returned by this function is created by a copy operation. In some cases the copy operation actually follows copy-on-write semantics, so that the actual physical copy of the bits occur only if the underlying data in the bitmap graphics context is modified.

So, when this function is called, the image's underlying bits may not be copied right away, and may instead wait to be copied when the bitmap context is next modified. This bit-copying may be expensive (depending on the size and colorspace of the context), and may disguise itself in an Instruments profile as part of whatever CGContext... drawing function that gets called next on the context (when the bits are forced to copy). This is probably what is happening here with CGContextDrawImage.k

However, the docs go on to say this:

As a consequence, you may want to use the resulting image and release it before you perform additional drawing into the bitmap graphics context. In this way, you can avoid the actual physical copy of the data.

This implies that if you will be finished using the in-memory created image (i.e. it has been saved to disk, sent over the network, etc.) by the time you need to do more drawing in the context, the image would never need to be physically copied at all!

TL;DR

If at some point you need to pull a CGImage out of a bitmap context, and you won't need to keep any references to it (including setting it as a UIImageView's image) before you do any more drawing in the context, then it is probably a good idea to use CGBitmapContextCreateImage. If not, your image will be physically copied at some point, which may take a while, and it may be better to just use a new context each time.

Reusing a CGContext causing odd performance losses

2 Answers2

TL;DR