Massive Memory Consumption

[dezinezync]

When using the Category with imageView.imageURL = aNSURL;, the memory consumption is insane. For a set of 500 images, of around 30-60Kb each, of JPEG format (flickr api, q sized), the memory consumption shoots up by a staggering 60-80Mb.

These image views are subviews of UICollectionViewCells. So when scrolling, the previous images should be removed from the memory for the time being.

I've boiled down the issue to ImageIO not releasing the ImageIO_JPEG_DATA object.

Further google searches on this bit have shown that using imageWithContentsOfFile causes this a lot, but the category never uses it. The entire file doesn't. So I'm a little confused as to what may be causing this.

I hope you get a chance to look into this at the earliest.

[nicklockwood]

It's because AsyncImageView stores the decompressed images in memory, not the original compressed ones. Decompressed images consume width_height_4 bytes of RAM, so they're much larger than the original file size, but they are much quicker to draw on screen.

I've added some logic to clear the cache if the memory runs out, so that should avoid any crashes due to the high memory consumption.

I'll look at caching the uncompressed images as well in a future version so you don't need to re-download if the cache is cleared.

[dezinezync]

Thanks for the clear explanation. I look forward to the update. Cheers,
Nikh.

On Fri, Jan 3, 2014 at 3:12 PM, Nick Lockwood notifications@github.com
wrote:

It's because AsyncImageView stores the decompressed images in memory, not the original compressed ones. Decompressed images consume width_height_4 bytes of RAM, so they're much larger than the original file size, but they are much quicker to draw on screen.
I've added some logic to clear the cache if the memory runs out, so that should avoid any crashes due to the high memory consumption.

I'll look at caching the uncompressed images as well in a future version so you don't need to re-download if the cache is cleared.

Reply to this email directly or view it on GitHub:
#39 (comment)