Over the last month or so, we have been looking at what appear to be large memory leaks in the Finder, specifically in its Icon and Gallery views. While I still await responses to my two Feedback reports detailing these, Neal has received a response to his earlier report, stating that this is intentional behaviour. This article considers the implications of that response:
“We believe this behavior is as designed, and is not a memory leak or abandoned memory. Instead, we expect we are caching the (large) thumbnails for the items selected in gallery view. We purge such cached thumbnails from memory periodically if they haven’t been used in the last two or three days, and we also perform more aggressive purges if the system is under memory pressure.”

What is the Finder doing?

In some Finder windows, specifically Gallery and Icon views, items can be displayed as large icons; in the case of image and movie files, those are normally thumbnails created by QuickLook from the contents of the file. Generating those thumbnails is a relatively costly process, so QuickLook maintains caches of them in storage. Even then, when scrolling through the contents of folders containing many such custom icons and thumbnails, fetching them all from cached files can be slower than the speed of scrolling.

To improve performance, the Finder thus retains copies of those images in memory, ready to display when needed. Provided that there’s no pressure on available memory, those cached images may be retained for up to 2-3 days before being purged, which then frees up the memory used to store those that are purged.

If you seldom use Gallery or Icon views, or other windows where thumbnails are displayed, then this behaviour has little discernible effect on the memory used by the Finder. However, if you often browse folders containing dozens or hundreds of items with custom thumbnails, the Finder can end up caching several GB of images. From my experience using Gallery view, that memory could readily amount to 1.5 GB for every 100 still image files. If you’re regularly working with folders containing several hundred such images, the Finder can happily cache several GB each day, and try to retain those for 2-3 days.

Testing

To assess this behaviour I tested a folder containing about 100 mainly JPEG photos, selecting various combinations of them in Gallery view. Within a few minutes, the Finder’s memory use rose from around 250 MB to just over 1.8 GB. Further selections in that Gallery view had no further effect on memory used, implying that at that stage all the thumbnails in that folder had been cached in the Finder’s memory.

My Mac (iMac Pro, 32 GB RAM, macOS 14.2) was then used as normal without returning to that folder or using Gallery view again over the following two days, and was neither allowed to sleep nor shut down or restart. Periodically I checked on the Finder’s memory use with Activity Monitor. Results are shown in the chart below.

The period during which I deliberately increased memory use in Gallery view is marked in yellow, and the line shows the Finder’s reported memory use. Over the following days, its memory use drifted steadily upwards, peaking at just over 2 GB by the morning of 18 December. Then, slightly over 2 days since I had last used Gallery view, the Finder purged its cached thumbnails from that session. The memory then used wasn’t the 250 MB that it had started with, as a result of additional memory cached after using Gallery view. This appears consistent with what Apple considers to be its expected behaviour.

At its peak, the Finder used more memory than the next three processes (WindowServer, MarsEdit and Postbox) added together.

Does the user expect this behaviour?

Before considering whether this behaviour is beneficial or not, it’s essential to consider whether users expect this of the Finder. You only have to look around discussion forums for a short while before you see users complaining of high memory use by the Finder, and comments to my previous articles here are consistent. Repeated searches of Apple’s support documentation have failed to locate any mention of what many users consider to be aberrant behaviour.

I think it’s fair to conclude that Apple has done nothing whatsoever to explain the Finder’s high use of memory, which many would consider to be a failing or bug. Indeed, I have reported this as a bug, as have several other experienced users.

Is this a good use of memory?

Apple’s own developer documentation on managing memory opens with the words:
“Efficient memory management is an important aspect of writing high performance code in both OS X and iOS. Minimizing memory usage not only decreases your application’s memory footprint, it can also reduce the amount of CPU time it consumes.”

Whether or not there is memory pressure, in Macs where the base memory is 8 GB, for one of the few apps that’s required to be running at all times to use more than half that memory can’t be considered to be a small memory footprint. For a great many users, apps that require more than 1 GB of memory are exceptional, and wouldn’t be considered to managing memory efficiently.

Memory has also become an expensive resource in modern Macs. Increasing use of fixed, non-expandable RAM has peaked in Apple silicon Macs, where the cost of an additional 8 GB is currently around $/€/£ 200, roughly ten times the cost of user-installable modules for fairly recent Intel models. The days of buying another 32 GB of relatively cheap RAM and installing it yourself are long since past. In these latest Macs, this is Unified memory, shared by CPU, GPU and other processing units. Although this does lead to some improvement in economy, it means memory used by the Finder is also in demand for use beyond the CPU.

The Finder’s caching of thumbnails is speculative, and only proves worthwhile when the user returns to browse the same folders and contents, enabling their thumbnails to be fetched from memory rather than disk. Retaining cached thumbnails for as long as 2-3 days seems to be betting on long odds that the user will view the same thumbnails again and again.

This type of memory-greedy behaviour should surely be the user’s choice: whether they want the Finder to cache GB of thumbnails to accelerate repeated browsing of the same files, or to minimise the app’s memory footprint. Rather than invite the user to choose a period of retention before automatic purging, it would also be better for them to set the maximum size of thumbnail and related caches. That could readily be incorporated in the Finder’s Settings.

What if other apps did the same?

Memory is a resource shared between all processes. What if other apps decided that they too would pursue aggressive caching policies as the Finder does? For document-based apps, it could be beneficial to cache most recently opened documents, as that would save significant time when the user re-opened them. If most other apps behaved likewise, this would become untenable, as they each contended for the same physical memory, and their caches had to be purged repeatedly because of memory pressure.

As Apple points out to developers: “Although caching can provide enormous benefits in terms of performance, there are also some possible drawbacks that caching presents. Most importantly, caching can use very large amounts of memory.”

Currently, the Finder can and does use very large amounts of memory. It may come to have the largest memory footprint of any process running on a Mac, and to hold onto that memory for two days or more. I don’t think that’s what many users expect, or want. Or am I wrong?