ImageIO_Malloc

[Werdan]

This is rather a clarifying question. I don't use specifically ImageIO anywhere in the program. All my images are PNG.

Yet, when I run the program through Instruments I get 600KB allocated to some ImageIo process. This is like 1/3 of what all the rest uses and I don't seem to have any intensive graphics

So I get the ImageIO_malloc inside copyImageBlockSetPNG... Maybe I am referring to all this wrongly, cause I have never used Instruments before, but I can't find anything on the topic and I would like to try to optimise my app. My images have lower size than 600KB, so don't get where this comes from...

[Duncan C]

Originally Posted by Werdan

This is rather a clarifying question. I don't use specifically ImageIO anywhere in the program. All my images are PNG.

Yet, when I run the program through Instruments I get 600KB allocated to some ImageIo process. This is like 1/3 of what all the rest uses and I don't seem to have any intensive graphics

So I get the ImageIO_malloc inside copyImageBlockSetPNG... Maybe I am referring to all this wrongly, cause I have never used Instruments before, but I can't find anything on the topic and I would like to try to optimise my app. My images have lower size than 600KB, so don't get where this comes from...

I bet you're using UIImage imageNamed: to load PNG images. That method caches the images in case you use them again. I haven't tracked down what that looks like in instruments, but I bet that's what you're seeing. For comparison, imageWithContentsOfFile: doesn't cache image data.

[Werdan]

Originally Posted by Duncan C

I bet you're using UIImage imageNamed: to load PNG images. That method caches the images in case you use them again. I haven't tracked down what that looks like in instruments, but I bet that's what you're seeing. For comparison, imageWithContentsOfFile: doesn't cache image data.

Brilliant! Thanks a lot!

[Werdan]

Originally Posted by Duncan C

I bet you're using UIImage imageNamed: to load PNG images. That method caches the images in case you use them again. I haven't tracked down what that looks like in instruments, but I bet that's what you're seeing. For comparison, imageWithContentsOfFile: doesn't cache image data.

I have changed all the imageNamed to what you have said and I still get this allocation. This is really strange. And it is more than just one allocation of 600KB.

It gets called once when I start the program, then when I display the popUp, and in smaller blocks (like 50KB) in many other cases.

Is there a way to trace all of this by memory addresses? How can I debug this?

[henryaz]

I had the same problem. No matter how I created the UIImage (+imageNamed:, -initWithContentsOfFile:, +imageWithData: ), I could track the UIImages being alloc'd and dealloc'd, and also the UIImageViews doing the same. However, this malloc'd memory from ImageIO_Malloc that you mention kept adding up and was never freed - each with a retain count of "1" (according to Leaks instrument).

I decided to attack UIImageView. Getting rid of UIImageView and using my own view to draw the image immediately solved the problem:

@implementation HFImageView

- (id)initWithImage:(UIImage *)anImage
{
	CGRect frame;
	frame.origin = CGPointZero;
	frame.size = anImage.size;
	if (self = [self initWithFrame:frame]) 
	{
        // Initialization code
		image = anImage;
		[image retain];
		self.userInteractionEnabled = NO;
	}
	return self;
}


- (void)drawRect:(CGRect)rect 
{
	[image drawAtPoint:CGPointMake(0, 0)];
}

- (void)dealloc {
	[image release];
	[super dealloc];
}

@end

Worked with all three ways of creating the UIImage.