You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm running the Demo App on an iPad 3 and getting 25 FPS when scrolling up and down (20 FPS without #125). The app becomes CPU-bound once each cell is changing every frame. An iPad 3 does not have the CPU to create 100+ UIImages, assign them to UIImageViews and commit the changes to Core Animation.
A workaround I have on this branch is to wrap every image fetch in a NSBlockOperation. The operation guarantees that the app will get 60 FPS because it avoids returning all 100+ images in a single frame. This is most noticeable on an iPad 3, which can only perform ~7 image updates per frame.
I feel that the cache should provide async and cancellable requests, by default, so that every use of the cache does not need to implement its own throttling. Regardless of the speed of the device, and no matter how amazing the cache, there is always a limit on the number of images that can be fetched in a single frame because each request takes a non-zero amount of time.
Thoughts?
I am happy to work on this, given a bit of guidance on the internal threading and the callback structure of the image cache.
I don't have an iPad 3 at home, but I ran some tests on older iPhones and didn's see anything unusual. I do need to track down this device. What version of iOS is it running?
The image cache isn't slow, UIKit is. I'm testing the performance on an iPad 3 because the iPad 3 historically has the worst graphics performance of any iOS device.
Replacing the table view cell's call to retrieveImageForEntity:withFormatName:completionBlock: with asynchronouslyRetrieveImageForEntity:withFormatName:completionBlock: solves the frame rate problem, but then it becomes possible to overload the cache.
2016-02-08 11:09:27.974 FastImageCacheDemo[196:18240] FICImageTable - unable to evict entry from table 'com.path.FastImageCacheDemo.FICDPhotoSquareImage32BitBGRAFormatName' to make room. New index 400, desired max 400
2016-02-08 11:09:28.137 FastImageCacheDemo[196:18240] FICImageTable - unable to evict entry from table 'com.path.FastImageCacheDemo.FICDPhotoSquareImage32BitBGRAFormatName' to make room. New index 401, desired max 400
2016-02-08 11:09:28.289 FastImageCacheDemo[196:18240] FICImageTable - unable to evict entry from table 'com.path.FastImageCacheDemo.FICDPhotoSquareImage32BitBGRAFormatName' to make room. New index 402, desired max 400
2016-02-08 11:09:28.442 FastImageCacheDemo[196:18240] FICImageTable - unable to evict entry from table 'com.path.FastImageCacheDemo.FICDPhotoSquareImage32BitBGRAFormatName' to make room. New index 403, desired max 400
...
Note: I did change the demo app to have 5000 unique photos instead of 100, because 100 photos never exercised the cache's 400 image limit.
@mallorypaine It looks like I am reproducing #82 with the demo app. The code I am running is here. Should the cache not have a overflow list for the extra images when there are more images requested than can fit in the cache?
I was scrolling down fast enough to get 400+ requests in-flight at the same time. I guess it depends on the device but it was easy with the iPad 3, which can only process a few images a second.
Activity
[-]Demo App getting 25 FPS on iPad 3[/-][+]25 FPS on iPad 3[/+]mallorypaine commentedon Feb 5, 2016
I'll need to investigate what has happened to performance. On device, we should be achieving 60fps without issue.
mallorypaine commentedon Feb 5, 2016
I don't have an iPad 3 at home, but I ran some tests on older iPhones and didn's see anything unusual. I do need to track down this device. What version of iOS is it running?
Axlle commentedon Feb 8, 2016
It's running iOS 8.4.
The image cache isn't slow, UIKit is. I'm testing the performance on an iPad 3 because the iPad 3 historically has the worst graphics performance of any iOS device.
Replacing the table view cell's call to
retrieveImageForEntity:withFormatName:completionBlock:withasynchronouslyRetrieveImageForEntity:withFormatName:completionBlock:solves the frame rate problem, but then it becomes possible to overload the cache.Note: I did change the demo app to have 5000 unique photos instead of 100, because 100 photos never exercised the cache's 400 image limit.
Axlle commentedon Feb 9, 2016
@mallorypaine It looks like I am reproducing #82 with the demo app. The code I am running is here. Should the cache not have a overflow list for the extra images when there are more images requested than can fit in the cache?
mallorypaine commentedon Feb 9, 2016
What are your exact steps to repro #82?
Axlle commentedon Feb 9, 2016
I was scrolling down fast enough to get 400+ requests in-flight at the same time. I guess it depends on the device but it was easy with the iPad 3, which can only process a few images a second.
mallorypaine commentedon Sep 12, 2016
I believe your PR addressed this.