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:
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" ) 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?