4 ms·
Load images lazily — only when needed — to avoid wasting memory upfront. AsyncImage or Kingfisher are the options. Kingfisher and AsyncImage decompress images
by conradev 1y ago
Load images lazily — only when needed — to avoid wasting memory upfront. AsyncImage or Kingfisher are the options.
Kingfisher and AsyncImage decompress images into dirty memory, and images are big. They're fairly CPU and memory inefficient from that perspective.
FastImageCache uses memory mapping and is very efficient, but it's 10 years old: https://github.com/path/FastImageCache https://github.com/path/FastImageCache
If anyone wants to build a modern rkyv + FastImageCache hybrid…
- jamil7 1y agoIs Nuke any different? I know it’s author wrote a lot about performance but I’ve never looked into it.
- conradev 1y agoNuke also uses a simple filesystem cache, so its the same: https://github.com/kean/Nuke/blob/main/Sources/Nuke/Caching/DataCache.swift https://github.com/kean/Nuke/blob/main/Sources/Nuke/Caching/... The framework is lean and compiles in under 2 seconds It compiles fast, though!
- ethan_smith 1y agoNuke (https://github.com/kean/Nuke https://github.com/kean/Nuke) is a modern alternative that handles efficient memory management with features like progressive decoding and intelligent prefetching.
- conradev 1y agoIt does progressive CGImage decoding right, I do remember looking at that! Efficient for network to pixels. But it stores PNGs on disk.
- JamesSwift 1y agoSo does FastImageCache as far as I can tell? But it also maps it to a packed sprite sheet before writing
- JamesSwift 1y agoThe two approaches seem to serve different use cases. Mapping to a sprite-sheet (how FastImageCache describes itself) doesnt matter if images arent actually reused often (eg doom scrolling). But if you do tend to either reuse the same image or scroll up/down on the same content then yes it will come out ahead. Ive seen a lot of async image loaders over the years on ios and for the most part they were all fine. The async offload and pushing remote url loading to the background is the most important part of what was historically missing from the first party ios api.
- conradev 1y agoI largely agree. The other thing that happened is that phones got faster: it just doesn't matter as much anymore. A slow disk cache is fine, but if it does anything on the main thread: straight to jail. The article is about memory efficiency, though! In order to get equivalent memory behavior the buffers would need to be marked as purgeable (from the article) so that kernel can empty the cache if needed. Not sure if any of these libraries do that. The main situation where cache speed is tested is app launch: load every image for the current viewport simultaneously. It can take some time if your images are slow to decode.
- saagarjha 1y agoI feel like there’s this misconception that mapping data from disk is free (this is also mentioned in the README you linked). It’s not. If the pages are clean then you do get the benefit of being able to discard them when pressure is high, but if you need them again they have to be paged in. And for most apps there is no sharing of this data, so loading it will be accounted for against your process rather than being amortized across several like system libraries might be. Sure, it’s definitely better than dirty anonymous pages, but it’s not free.
- frumplestlatz 1y agoBack on the iPhone 3G, PNG decoding alone was slow enough that I had to cache pre-rendered bitmap representations into SQLite blobs to achieve "glassy" scrolling of image-heavy grids; I'd do the SQLite loading on a worker thread and dump the pre-rendered bitmap representation right back into a CGImage wrapper. I recall there being some inline NEON assembly involved as well. Within 1-2 years, those optimizations were totally unnecessary.