Recently, QRecall has been very sluggish to update the "QRecall Activity" window that appears when backup operations are in progress.

Previously, the seconds on the timer would tick by regularly; the file names listed after "Capturing" would whiz by dozens of times per second, and the numbers for the amount captured, MB/min, and so forth would update frequently.

This was the case when I was running High Sierra 10.13.2, backing up from one SATA SSD to an archive on another SATA SSD.

A few days ago I switched my main drive from a SATA SSD to a PCI-E (m.2) SSD. That seems to be when I first noticed the problem although I can't imagine why this would matter.

Tonight, I started a backup to a brand new, empty archive. It's been a while since I've done this but I'd expect performance to be in the gigabytes per minute range since no comparisons with older versions would be required. The backup has been running for 20 minutes now, with constant disk activity light indication, and the Activity window has been stuck on "950.5MB, 12% duplicate" and "26.4MB/min" since the first minute. Looking at the archive in the Finder shows a size of 1.15GB, last updated 20 minutes prior (although I don't know how often this file info is updated). The backup timer, far from updating consistently once per second, stays the same for 30-120 seconds at a time.

File names shown after "Capturing" stay up for minutes at a time. And these are not multi-gigabyte files.

The source volume is APFS, and the archive volume is HFS, but that was the case previously. Right now the progress indicator bar has not a single pixel of blue in it. Honestly I'm not sure if the backup is actually, you know, backing up.

Any suggestions or explanations would be appreciated.

[UPDATE]

At 49 minutes in, the window's updating much more frequently now. The file names change and the backup timer ticks pretty regularly. However, only about 10GB has been backup up so far and the current backup rate is about 20MB/minute. At this pace it will take, let's see, about 70 hours for a full backup of my 850GB of data...

[UPDATE]

The proximate problem appears to be that the "iconservicesagent" process is hogging a tremendous amount of CPU time, up past 100%. Sigh. Time for more investigation...

David Ramsey wrote:The proximate problem appears to be that the "iconservicesagent" process is hogging a tremendous amount of CPU time, up past 100%.

This is the culprit. Apple seems to have consolidated icon lookup/management/generation into this new background service. The bad news is that this service is really, really, slow—at least at the onset.

I don't know if it's the 10.13 upgrade, the APFS conversion, or some combination of both, but after installing High Sierra this process was driving me nuts. QRecall captures were glacially slow, with iconservicesagent maxed at 100% CPU while everything else crawled along. I have a folder of about 1,200 Photoshop files, and it was excruciating to open. In icon view, I'd scroll a page and the Finder would freeze for 30 seconds, scroll down a little more, and another 30 second freeze, and so on.

I suspect that the icon information gets cached somewhere, because over time things have improved dramatically. Or possibly some of the performance problems have been addressed in 10.13.1 and 10.13.2. Anyway, about a month ago I stopped noticing iconservicesagent being a problem. I can still catch it on the top list, but it's now unusual, rather than the norm. My 1,200 Photoshop files scroll about as fast I can page down and captures are back to their regular speed.

So with any luck, this might eventually take care of itself. Remember that all captures are incremental. Just let the capture run, maybe overnight, and stop if it hasn't finished. It will pick up again where it left off when you start it again. Once you're caught up, merge the incomplete layers with the final one.

I think that's it. The other change that Couldn't Possibly Have Affected Anything was that I finally got my Hackintosh to sleep, so it not only had to do with a new drive-- which probably meant that it had to rebuild all those icon caches-- but it wasn't running more than an hour at a time.

I'll let it thrash for a day or so and hope things speed up.

[UPDATE]

By this morning, everything had completed, the system seems much more perky, and the iconservicesagent process is shown as having taken just over 3 hours of CPU time, but it currently taking 0% processor time...