We’ve been talking about some Core Graphics trickery recently, related either to fancy gradients used to create shiny buttons, or complicated clipping. I wanted to take a moment to time some of this stuff out on the iPhone, and see if there were any performance implications. There don’t seem to be.
Methodology
I kept my timing simple, and used a combination of NSDates and NSLog outlined here to measure my rendering. I only timed the gradient rendering itself, omitting most setup (including the time required to construct clipping paths) and averaged my timing over 300 runs (3 buttons, each drawn 100 times). The core measurement code looks like this:
NSLog(@"Begin image construction");
NSDate* startTime = [NSDate date];
for (int i = 0; i < 100; i++)
[UIButton drawGlossyRect:CGRectMake(0, 0, width, height) withColor:color inContext:context];
NSTimeInterval elapsedTime = [startTime timeIntervalSinceNow];
NSLog(@"End image construction");
NSLog([NSString stringWithFormat:@"Elapsed time: %f", -elapsedTime]);
All timing was done on an iPhone 3G.
Results
Here’s a table of my results; I timed the code in both debug and release mode for a variety of clipping cases, including:
- No clipping
- Clipping which renders most of the image
- Clipping which removes most of the image
- Clipping against complex shapes
 |
 |
 |
 |
|
| Debug | 3.13342 | 3.83123 | 3.84655 | 3.94069 |
|---|---|---|---|---|
| Release | 2.82005 | 3.67560 | 4.07792 | 3.78043 |
| Gain | 10% | 4% | -6% | 4% |
Summary
Some quick interpretations of this data:
- All 8 cases take between 3 and 4 ms. Assuming that you want your interface to render within 100ms (1/10th of a second being a reasonable rule of thumb for the longest imperceptible delay in a user interface) that means that you can render 5 of these images while consuming less than 20% of your available time. You probably don’t need to worry about the performance implications of Core Graphics operations at this scale.
- There’s surprisingly little gain in moving from a debug to a release configuration. While the 6% slowdown in one case is likely due to measurement error, there’s no mistaking the general lesson that the two configurations are very close in performance.
- In general, it’s a lot more expensive to clip than not to clip, and slightly more expensive to clip against more complex shapes.
- The number of pixels actually drawn has little if any effect on rendering time.
