What in DEVONthink interacts with sharedfilelistd?

DEVONthink
1

This has been happening for a while, since at least 3.8, and continues in 3.8.1: DEVONthink will regularly become unresponsive, showing a spinning beach ball. The episodes last for many seconds – I’d say on the order of 15-30 seconds. When I look at the summary of process statuses (using iStat Menus), I see this:

image

DEVONthink is top, but sharedfilelistd is second. This pattern is consistent.

At first, I suspected that it was due to a smart rule matching too many things and being executed periodically, but I’ve gone through all the rules and tweaked the conditions so that almost none of them currently show any new matches. (I’m experimenting with the two that still show matches.) I still think this may be due to my smart rules because this problem didn’t exist some weeks ago, and while it’s possible something else in my computing environment changed, the most likely cause still seems likely to involve smart rules. Restarting DEVONthink doesn’t cause the behavior to go away – I’ll run for a while normally and then boom, beach ball.

My current question is: what are the situations in which DEVONthink would trigger sharedfilelistd to use a substantial amount of CPU? The description that I can find of that daemon (" sharedfilelistd is a per-user agent that manages lists of recent and favorite documents, applications, and volumes" [1]) doesn’t really suggest a good reason for it to be triggered by DEVONthink like this, but still, the consistent pattern makes me think that whatever is happening in DEVONthink is something that also manifests itself as increased sharedfilelistd activity. So, perhaps this is a clue, and the DEVONthink developers may recognize it?

[1] https://keith.github.io/xcode-man-pages/sharedfilelistd.8.html

2

DEVONthink doesn’t use this on its own, most likely it’s used by the system’s handling of recent items (e.g. recent databases).

3

An additional data point. After experiencing it regularly over the past few weeks, I’ve narrowed down the conditions to when Time Machine backups are running, especially when TM is in the “preparing backups” phase and then the “cleaning up” phase at the end, but also often in the middle.

I don’t know why, or what is going on, but I’m mentioning it here in case it helps identify the underlying cause at some point.