Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
DaisyDisk very slow to scan in Sonoma
- Thread starter Morac
- Start date
- Sort by reaction score
Yes, unfortunately this issue in Sonoma still persists. I keep posting updates to my bug report to Apple, but so far there has been no response from them.
No, it's not related to SSD.
My further research has shown that apart from ~/Library/Containers, other privacy-sensitive folders like ~/Documents, ~/Desktop etc. are also relatively slow to open - but only on their root level - and their subfolders are opened quickly, so no slowdown is noticeable. By contrast, all recursive subfolders of ~/Library/Containers are slow to open.
The slowdown occurs due to an expensive security check that macOS performs on each call to open a subfolder inside ~/Library/Containers. The security check may involve calculating the hash of the calling executable, because the duration of the delay clearly depends on the calling app's file size. Besides, there seems to be only one system thread that performs the check - so that if many threads are asking to open a folder simultaneously, they have to wait for each other in a queue, which creates a real bottleneck in performance.
All in all, it seems that this new "security feature" of macOS Sonoma was implemented without much thought about performance. Not to mention that when the user grants the "full disk access" to an app, the security check for it must not occur at all, but it does occur, unfortunately.
I really hope Apple will notice the problem.
No, it's not related to SSD.
My further research has shown that apart from ~/Library/Containers, other privacy-sensitive folders like ~/Documents, ~/Desktop etc. are also relatively slow to open - but only on their root level - and their subfolders are opened quickly, so no slowdown is noticeable. By contrast, all recursive subfolders of ~/Library/Containers are slow to open.
The slowdown occurs due to an expensive security check that macOS performs on each call to open a subfolder inside ~/Library/Containers. The security check may involve calculating the hash of the calling executable, because the duration of the delay clearly depends on the calling app's file size. Besides, there seems to be only one system thread that performs the check - so that if many threads are asking to open a folder simultaneously, they have to wait for each other in a queue, which creates a real bottleneck in performance.
All in all, it seems that this new "security feature" of macOS Sonoma was implemented without much thought about performance. Not to mention that when the user grants the "full disk access" to an app, the security check for it must not occur at all, but it does occur, unfortunately.
I really hope Apple will notice the problem.
I’m hoping MacOS 15 does something with the new “app data” permission because as mentioned, it seems like it was tacked on at the last minute in Sonoma. The permission doesn’t even appear in the Privacy & Security settings. I would expect it to be under Files & Folders but it’s not so there’s no way to tell what Apps are allowed to access other App’s data or grant/revoke it.
Also one would think Full Disk Access would override all of that, but it doesn’t.
Also one would think Full Disk Access would override all of that, but it doesn’t.
Sorry, I haven't checked Sequoia yet. My past experience with early betas of macOS updates has shown that it makes little sense, because you will see a lot of bugs, panic, spend a lot of time trying to fix them all, only to find out they were macOS bugs which got magically fixed in later macOS beta updates. So I will wait a little bit and then check, and let you know!
Now that I've updated to Sequoia, I can also confirm that `ncdu` is back to its former fast scan. So it would appear that the problem has been solved by Apple.
The fix has not been backported to Sonoma, however.
Thank you guys for sharing your results. I'm glad to hear that it's got better for you with Sequoia, and I'm holding my fingers crossed that Apple has indeed addressed the issue based on our feedbacks. That said, I have to make the reservation that we'll still need more data to prove that the issue has been fixed indeed. I noticed that sometimes the scanning speed gets back to normal when the Containers folder is cleared and reset, which may be the case after upgrading the macOS version, and then gradually gets back to slow when more subfolders are created by apps. I hope this is not the case!
I’ve used DaisyDisk dozens of time since Sequoia was released and have yet to experience any slowdowns.
Not only that but a script I wrote to clean out thousands of temp files from an app container, now runs in seconds as opposed to minutes like it did under Sonoma.
I consider the issue resolved.
Not only that but a script I wrote to clean out thousands of temp files from an app container, now runs in seconds as opposed to minutes like it did under Sonoma.
I consider the issue resolved.