

This is where you would expect most memory to be consumed. This is when the image is getting decompressed from JPEG and put into memory. This is just showing in instruments where the image decoding is occurring. There isn't an issue with that code.
I always receive memory warning, from the instruments I get the above result.The decodedImageWithImage consume a lot of memory锛孲o I want to know whether there are other ways to reduce memory usage
I'm having same issue. I have iPad app that loads lots of images and app was crashing, ran in Profiler using the Allocation template and decodedImageWithImage is using 200+MB in my app which then causes memory warnings and crash.
Also this memory shows up as Live Bytes surely this would great released once the image decoding has finished?
I'm having the same problem too. Though it's not a library issue it does cause problem on some device like iPhone 4S. Same code runs totally fine on 5S, with more room to claim and release the memory.
I found this thread on stack overflow which presents a different way to decompress an image introduced with iOS7:
http://stackoverflow.com/questions/22994153/image-decompression-in-ios-7
Maybe this could help decrease memory used in the process...
I will have a look at it as soon as I have a minute.
+1,
as temporary solution I've modified the decodedImageWithImage, by just returning the image passed
My question is when my app back to background, how can I explicitly release these memory since my app doesn't need to display the images when it is in background state.
decodedImageWithImage takes up huge memory and causes the app to crash. This happens if you are loading 100s or 1000s of images (not even high resolution). This was tough to find as the stack trace didn't lead to this category when the crash happens. I have added an option to put this off in the library but defaulting to YES so there aren't any break in changes.
This is indeed a problem here. But I'm less worried about the memory pressure this creates, but i am worried because it seems it's never released until persisted memory reaches above 300mb. Is this an enumeration-without-an-autorelease problem? I haven't jumped into the source yet, but this expansion seems to have gotten worse from older versions. I'm seeing long lived CGDataProviderCreateWithCopyOfData caused by decodedImageWithImage Maybe i'm only seeing it now because of larger devices, larger photos, etc?
Wasn't there just a recent change on maximum concurrent downloads? I could see that exacerbating this issue.
Maybe we are conflating this issue with something else. I see no problem with a huge VM CG Raster Data, but i'm noticing a lot more memory warning than the past. Let me try and isolate the didReceiveMemory events, maybe it's more related to prefetching
Actually it looks like a lot has already been done on this front
https://github.com/rs/SDWebImage/pull/996
https://github.com/rs/SDWebImage/pull/884
@bpoplauschi you should close all these duplicates already being tracked https://github.com/rs/SDWebImage/issues/538
same here, this takes a lot of memory, and don not release.

We are having the same problem. Short circuiting decodeImageWithImage with a "return image" seems to solve our problem, and hasn't seemed to cause any problems. At least not yet.
This seems to have been open for a while. Any chance of this being addressed @rs ? I don't want to have to use some separate fork, or ditch SdWebImage altogether, but we can't live with this as an issue.
We did some modifications to it and is working for us; fixes the crash.https://github.com/harishkashyap/SDWebImage
This appears to still be buggy on 3.7.3. I'm loading a total of 30 images and seeing a roughly 300mb allocation from this method
same here
is there any workaround to solve this memory issue ? Any help or guidance will be very helpful.
@krupanshu
shouldDecompressImages available for both
SDImageCache & SDWebImageDownloader
[[SDImageCache sharedImageCache] setShouldDecompressImages:NO];
[[SDWebImageDownloader sharedDownloader] setShouldDecompressImages:NO];
Is anyone actually seeing crashes as a result of this?
I'm fairly confident that ImageIO is smart enough to manage it's own cache and the increase in perceived memory usage is actually okay. It will purge as necessary. It seems to be a little greedy, but that's actually fine so long as it's not being "too" greedy and crashing your app as a result of this.
Same as #538.