jbeans, thanks for the code snippet. I am posting my solution in the hopes it helps someone else.
i compared your solution with mine ( and code i posted). I found the implementations to be similar. I took your advice and focused on the objective c portion.
To clarify my earlier post I was not experiencing leaks per se, but found that resources were not being freed as promptly as I would have liked leading to app termination. Using Instruments I tracked these down to the following allocatioons:
Category: VM CGImage
Responsible Caller: CGBitmapAllocateData
size : 5.5MB
size 4.88 MB
these allocations were occurring once per loop (see for loop in my initial post). They were not released within the loop. Memory continued to grow till termination. I ultimately updated my code as follows:
int n = 0;
CGRect frame = CGRectMake(0,0,600,600);
// allocate & init view outside loop.
// re-use it inside loop
BatchChartView *v = [[BatchChartView alloc] initWithFrame:frame];
for( b in _batches)
// write image to disk (full sized imag)
NSString *fileName = [NSString stringWithFormat:@"chart.%d.jpg",n++];
NSString *imageFilePath = [NSTemporaryDirectory() stringByAppendingPathComponent:fileName];
// using autoreleasepool here permits CGBitmapAllocateData (from within getImage) to be
// released promptly
// save image to temp directory. chart.#.jpg
UIImage *batchChart = [v getImage];
NSData *imageData = UIImageJPEGRepresentation(batchChart, 1.0);
NSLog(@"%s %d: length %lu", __func__ , __LINE__ ,(unsigned long)[imageData length]);
[imageData writeToFile: imageFilePath atomically:YES];
imageData = nil;
batchChart = nil;
v = nil;
1) within the loop, the @autoreleasepool addressed the CGBitmapAllocateData (via getImage) allowing this to be released promptly.
2) Rather than alloc & init view & embedded chart with each item in the loop, I moved the initialization outside the loop & reuse the view. This eliminated the multiple SChartCrosshair allocations.
jbeans, thanks for your help. Your insight got me looking in the right place(s).