Closed
Description
Hello everybody,
I'm sorry in advance as maybe this is a dumb and noob question...
I'm using SDWebImage to display pictures in a UITableView in my cellForRowAtIndexPath method, using the classic
[cell.pointPicture setImageWithURL:[NSURL URLWithString:thePoint.imageURL] placeholderImage:[UIImage imageNamed:POINT_DEFAULT_IMAGE]];
(the displayed pictures are light and well compressed jpgs, just some ko)
When I inspect my app with "Instrument - Allocations", and just scroll down my UITableView (with 40 cells containing picture, a bit like Instagram), I got a huge amount of memory used ! (see screenshot)
But it seems to be "VM", and especially "VM: CG raster data" from the coreGraphics library.
So the questions are :
- Is it normal?
- Is that a serious problem?
- Is there a way to avoid this?
I'm sorry but after few search on the web I can't find any relevant information concerning the "VM: CG raster data"... Any idea? Thanks in advance !
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
No branches or pull requests
Activity
ivanbruel commentedon Oct 28, 2013
I am indeed having the same problem on an iOS7-only app. Images don't seem to be recycled. Seems to be related with [SDWebImageDownloaderOperation connectionDidFinishLoading:] and the ForceDecode of the UIImage.
kefon commentedon Oct 28, 2013
@ivanbruel nice to know that I'm not the only one ;) I still looking to understand the problem, but unsuccessfully for now...
kefon commentedon Oct 28, 2013
I also have the same issue while running the SDWebImage demo project (on iOS7 / iPhone 5)
rs commentedon Oct 28, 2013
SDWebImage cache images is using NSCache. It is discardable memory. See Apple documentation: https://developer.apple.com/library/ios/documentation/cocoa/reference/NSCache_Class/Reference/Reference.html
kefon commentedon Oct 28, 2013
@rs Ok ! So if I understand, this is a perfectly normal behavior and the memory is released if needed. Thank you for your answer, now I think I understand what's going on. Sorry for the noob question ! (So I can close this issue right?)
ivanbruel commentedon Oct 29, 2013
Well, from my particular issue, I'm URLing into the documents folder, the memory keeps growing no matter how many passes I make through the list, it will most of the time fetch them from disk instead of memory. So does this mean the discardable memory is being discarded even while it grows?
cloay commentedon Nov 5, 2013
I have this issue only on iOS7. How to avoid this?
mrtristan commentedon Nov 5, 2013
i see this too, are we thinking this isn't an issue? @rs are you saying the memory will grow and grow until it actually needs to be reclaimed?
rs commentedon Nov 5, 2013
Yes, it's caching
williamkey123 commentedon Nov 7, 2013
I am seeing a lot of crashes as the CG raster data grows - it doesn't look like it's actually discarding memory when it needs to be. I see memory warnings start to get generated, it kills background apps, and then the app crashes without ever discarding any of the CG raster data.
phionardo commentedon Nov 7, 2013
I have exactly the same issue, too. @rs Is there a way to clear cache timely, or reduce using memory for caching?
In my case, the "All Anonymous VM" grows to 700MB and my app crashes, due to the huge amount of "CG raster data".
rs commentedon Nov 7, 2013
We could play with the
totalCostLimit
ofNSCache
to implement a maximum used memory barrier.williamkey123 commentedon Nov 7, 2013
I added this:
But I'm still getting this as I scroll through a UITableView with lots of images:
Note the CG Raster Data is still blowing up and it's killing other apps but never reducing the raster data.
Is there something I should be doing to release the images in the table cells when the cells are dequeued and reused? Sorry if that's a stupid question.
rs commentedon Nov 7, 2013
I guess you have to set the cost of each entry at insertion time otherwise it can't work.
williamkey123 commentedon Nov 7, 2013
Looks like right now it's setting a cost for each entry of the image height * width * scale as an approximation for image size... I've changed this to:
In the three places where setObject happens - but memory usage is still exploding. I have it capped at 80 MB but CG Raster Data continues to increase unbounded... I suspect this could be the way CoreGraphics is storing rendered images in the view and has nothing to do with the cache that SDWebImage is keeping. But I just have no idea how to tell CG how to free this raster data when it's not on screen.
127 remaining items
bpoplauschi commentedon Jun 15, 2016
We have replaced our GIF component with FLAnimatedImage. You can try our 4.x branch (instructions).
songshp39 commentedon Sep 6, 2016
image = [[UIImage alloc] initWithData:data];
This init method will bring in a memory spike when the image data is larger than 1M.
bpoplauschi commentedon Sep 29, 2016
Closing. The FLAnimatedImage solution replacing our own GIF is integrated into the 4.x branch.
bpoplauschi commentedon Oct 1, 2016
@mythodeia @rs it seems that 3 different people created PR's with the same idea of fixing some of the memory issues we have: scaling down the large images: #787 #884 #894. Do you think it is a good idea? Which one do you prefer? If we merge any of them, I would go with a
SDWebImageScaleDownLargeImage
option so people can go around it if they really need to.mythodeia commentedon Oct 1, 2016
@bpoplauschi #884 and #894 are almost the same.From these two i prefer #884.
Now for #787 i would like to see some benchmarks and the code needs some cleanup.
However i like the idea of making it optional like you said
bpoplauschi commentedon Oct 6, 2016
@mythodeia I agree. Now since I saw that #787 was the most solid PR and it also included the Apple sample for downscaling, I considered including it is best. I merged it via 959d965 (of course it had conflicts and I updated the code). Then I added another commit 00bf467 cleaning stuff up in the Decoder class. Take a look and let me know what you think. We still need to bechmark it.
Everyone, #787 and 00bf467 should give you a good solution for dealing with large images. Together with the GIF handled by FLAnimatedImage, this ticket should be done now.