Closed imhuntingwabbits closed 11 years ago
skurfer
commented
11 years ago -[NSWorkspace iconForFile:] usually runs extremely quickly and just returns a generic icon based on type. The more expensive Quick Look preview stuff is then done in the background, but it's not getting to that point in the sample above. Do you have any idea which files it might have been looking at when the sample was taken? Do you have any files in your catalog on an external or network volume?
pjrobertson
commented
11 years ago Yes, we are aware of this problem
@skurfer shouldn't this be fixed with your changes in #1369? IF so, it will be fixed in an upcoming Quicksilver version (not the next, but the one immediately after that.
imhuntingwabbits
commented
11 years ago I have two external volumes, but I don't think quicksilver is indexing them. One is a set of low power drives that frequently sleep, its annoying and OSX seems to block waiting for them to wake up.
Is there a way I can get a list of all items in the catalog? I could grep that for the names of my external volumes.
skurfer
commented
11 years ago No, that won't fix it. I moved things around to make more sense, but it will still call -[NSWorkspace iconForFile:] on the main thread, then do the Quick Look stuff in the background.
@imhuntingwabbits: Look in ~/Library/Caches/Quicksilver/Indexes. The files there are just XML property lists, so grep -r should do the trick.
imhuntingwabbits
commented
11 years ago Yep, my external drives are in the indexes files. Is unchecking the boxes in Catalog -> System -> Devices -> Disks enough?
skurfer
commented
11 years ago Maybe. Some files tend to get picked up by multiple catalog entries, but probably not those on an external drive.
Unchecking that will remove the top-level volume itself, but I'm not sure if that would explain the problem. Seems like it wouldn't really slow down unless it was trying to look at files on the disk.
Do you have the "Show children in result list" preference enabled?
imhuntingwabbits
commented
11 years ago Not that I know of, where do I find that in Preferences?
skurfer
commented
11 years ago In the prefs, choose “Command” on the left. It’s at the bottom under “Results”.
imhuntingwabbits
commented
11 years ago Nope, not checked.
skurfer
commented
11 years ago OK. It's a common source of slowness, which is why I asked.
I did some testing with a slow-to-wake USB drive at work. It's in the catalog, but searching for it and seeing it in the results never leads to any delays. Only if I try to look at a file inside it will the delay occur. Do you have custom icons assigned to any of these volumes? If so, it might need to access the icon file from the volume itself just to show it in the results. Or, could some of the files contained within these volumes be getting added to the catalog?
imhuntingwabbits
commented
11 years ago No custom icons but indeed it looks like "Find All Applications" picked up an app that I have archived on one of my external drives.
pjrobertson
commented
11 years ago So is this issue reproducible on a regular basis, or only sometimes? It's quite possible that Apple's iconForFile: method is buggy and hanging.
I'm assuming 10.8.3 didn't fix the problem?
imhuntingwabbits
commented
11 years ago No it only reproduces when the system puts my external drives to sleep. I turned that option off in energy saver preferences and things appear to be better.
If you like file a radar with apple for blocking on disks that don't need to be queried and ill track that / pile on internally.
To be clear, my issue with quicksilver is that this is done on the main thread. But if the underlying system is waking volumes up it doesn't need to that sounds like a bug in the underlying framework.
skurfer
commented
11 years ago I'm not ready to blame it on the OS just yet. What we're doing on the main thread is asking for a generic icon. While that will almost always be stored on the local disk no matter what type of file it is, it may have to go to the external disk to retrieve the type information before asking the local disk for the icon. It looks like that's the case from the trace above. We could try calling iconForFileType: instead to throw up the initial icon, but I suspect that will give incorrect results for files with customized icons. Of course, we could overcome that by moving the call to iconForFile: to loadIconForObject: (which runs in the background). Now I'm just rambling. :finnadie:
I think @pjrobertson's change to QSObject_FileHandling.m in #1488 will eliminate some of these delays.
Looks like trying to fetch an icon off disk is blocking the search results coming back.