Hacker News Reader

Comment by conradev | Hacker News Reader

  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

If anyone wants to build a modern rkyv + FastImageCache hybrid…

View on HN

Nuke (https://github.com/kean/Nuke) is a modern alternative that handles efficient memory management with features like progressive decoding and intelligent prefetching.

It does progressive CGImage decoding right, I do remember looking at that! Efficient for network to pixels. But it stores PNGs on disk.

So does FastImageCache as far as I can tell? But it also maps it to a packed sprite sheet before writing

I 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.

Back 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.

The 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.

I 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.

Is Nuke any different? I know it’s author wrote a lot about performance but I’ve never looked into it.

Nuke also uses a simple filesystem cache, so its the same: https://github.com/kean/Nuke/blob/main/Sources/Nuke/Caching/...

  The framework is lean and compiles in under 2 seconds

It compiles fast, though!

Reply on news.ycombinator.com