Alfred pause while secondary HD spins up

[voxel]

Hi

 

First. Thank you for making Alfred. It's a really great piece of software that I use every day

I have had this issue for maybe a year now where sometimes when I open the alfred search window and try to start to type anything, alfred freezes for maybe 5-15 seconds (varies a bit) before the first letter shows up. This is quite annoying, especially as I use alfred as a calculator very often. I have held off on reporting it because I thought it would be noticed by someone else and fixed in a short while.

From what I can tell, the issue is caused by that alfred is blocking on IO. It seems very well correlated with my other hard-drive spinning up (which I use for very little, so it is usually sleeping and not spinning). I also noticed a similar effect when downloading a very large game from steam. In that case my ssd (not my other hard-drive) was being written to with 10-15 MB per second, and alfred was really laggy during this time. I do not expect alfred to work well when there is such a load on the disks, many other programs were also very laggy when it happened. I only mention it because it seems to also indicate that alfred's UI thread seems to be blocking on IO quite a lot.

 

The first issue is more annoying though. It seems alfred is sometimes trying to read some file (or just metadata) from my other hard drive, which causes it to start to spin up. That in itself is not a big deal, but it is very annoying that the UI thread is being blocked by it.

I am not sure how alfred is structured internally, and what info is read from an index, and what needs to be read from disk every time. I am guessing that things like the name, type and location of the item is stored in an index, while things like the icon might require reading the file or its metadata (and thus potentially waking that drive from sleep). It looks like the icon is already loaded asynchronously. So I'm thinking a possible solution could be to read any other such info asynchronously and then fill the list in (as with the icon) when it is available. To avoid flicker in common cases when the drive is pretty fast, you could perhaps block for up to say 50 milliseconds and if the file hasn't been read by then, you display placeholder info (e.g a transparent icon).

 

I have not managed to capture a video of this because it is quite hard to catch. If I miss it once, I have to wait until the drive goes to sleep again before it could potentially be triggered again.

For similar reasons I also haven't managed to capture a trace or sample of the process when it happens.

 

OS X El Capitan: 10.11.6 with a 3.99 GHz Intel Core i7, 16 GB RAM with an NVIDIA GeForce GTX 970 GPU.

Alfred v3.6.2 [922].

My main disk is a 250 GB SSD and my other one is a 3 TB internal hard drive.

 

Thanks in advance,

Aron Granberg

Edited August 4, 2018 by voxel

[Andrew]

@voxel Alfred, by default, doesn't read anything off of your non-primary drives to prevent issues like this from happening. I have even added an option to use file type icons on external drives to prevent things from spinning up unnecessarily (see screenshot).

 

One thing which may be causing this is having the second slower drive within your default search scope. Alfred runs the metadata queries asynchronously, but the callback involves some interactions with the main thread. Some Apple API calls which Apple claim to be non-blocking can, in rare configurations, cause blocking. I haven't heard this to be a problem for quite some time though, perhaps with newer iterations of macOS.

 

What is your default search scope set to? If it includes the drive which spins up, consider moving file search on this drive to a workflow so that the drive only spins up when you are in control of this. It may also be worth reindexing your Mac's metadata which may remove some stale metadata links between the data on both drives (which may fix this).

 

Cheers,

Andrew