Speed much slower after last release #2090
Assignees
Labels
Comments
|
Keep Activity Monitor handy with Quicksilver selected. When you see a hang, use it to run Sample Process from the gear menu. Anything I can think of that would explain this was already in the previous version. Did you skip over 1.2.x? |
|
Quicksilver is behaving at the moment, I'll keep activity monitor open and see if I can catch it in the act :) I'm not sure if I skipped over 1.2.x or not, the main thing I remember from the release notes is that the smart spacebar functionality was added. I update it whenever it asks, this was the first update in quite a while (over a year?). I'm currently on 1.3.0. |
|
OK, I caught it, I have no idea what I'm looking at here, hopefully nothing too personal is in this: |
I think I know what’s going on. If you can live without the “Recent Objects” catalog entry, disabling it might help until we can fix it.
No, you’re safe. |
|
Thanks Rob! I disabled it for now, let me know how it goes. On August 26, 2015 at 10:20:36 PM, Rob McBroom (notifications@github.com) wrote: I have no idea what I'm looking at here I think I know what’s going on. If you can live without the “Recent Objects” catalog entry, disabling it might help until we can fix it. hopefully nothing too personal is in this No, you’re safe. — |
skurfer
added a commit
that referenced
this issue
Aug 31, 2015
This was referenced Aug 31, 2015
|
I’m also seeing this issue, and I had the “Recent Objects” Catalogue entry disabled all along. I have now also disabled “Recent Commands”, and things seem a little faster, but still not as near-instant as I’m used to, and I don’t know if there is a correlation with “Recent Commands” yet. Either way, I’d be happy to help debug this, or test pre-release versions to see if this is already addressed by the referenced commits and issues. |
|
I have witnesses the same sluggishness. I went from v1.2.2 to v1.3.1. I tested v1.3.0 and notice the same behavior. For the moment I've downgraded to 1.2.2 until this issue it resolved. thanks |
|
Activity Monitor : Quicksilver: Bytes Written = 62GB. Ack! |
Yikes! How long has it been running? Are you using the Copy To… or Move To… actions much? |
|
Nope, not doing anything strange. I've rebooted lately, so kinda strange so much written. Any way to tell what it is writing? Note: corp laptop, so it could be fighting with a monitor app? -Benjamin
|
That is strange since Quicksilver usually writes very little to the disk to begin with. The only thing that comes to mind is the cache in
In Activity Monitor, if you select Quicksilver and hit the Info button, there should be an “Open Files and Ports” tab that tells you what it has open currently. That only works if you catch it in the act, but if it’s writing that much, I think your chances are good. |
|
My open files |
|
I'll describe my problem as "chuggy":
Here is sample from activity monitor of 1.2.2 vs 1.3.2:
I didn't look too deeply into it, but notably 1.3.2 is 513KB vs 1.2.2 for 186KB. thanks |
|
I've included videos on the above comment to show the chugginess. For 1.2.2, I didn't include visual for keystrokes however 1.3.2 I think represents exactly my experience. please reply if you can't view the videos, I can export them to alternative format if required. |
|
@lexinator It's hard to compare the two, because the v1.2.2 sample isn't actually doing anything related to keyboard input (it's mostly rescanning for processes and updating the action list). If you want a little more time to check, you can switch to Terminal and run v1.3.2 is, well, interesting... It's a little hard to say, but I have a hunch that it's doing 2 rankings back to back (1st A few other things you can try :
@skurfer Was 1.3.2 built on 10.11, by any luck ? I'll |
|
@tiennou interesting on the samples, because in both cases I was typing as the sample was occurring. I will try again and post results. Wouldn't 1.2.2 and 1.3.2 have the same catalog size? I guess not based on below. It looks like safari history is the big outlier: The number I see in 1.2.2 is:
The count i see in 1.3.2 is:
|
|
Yeah, it's quite hard to synchronize with the sample. I just discovered that running from the command line can be more accurate because you see the "Sampling process 71231 for 10 seconds with 1 millisecond of run time between samples" instead of some useless progress bar. Now that history count sure looks crazy to me... so that would explain your performance. Also, was the cache cleaned before getting those numbers ? I don't get how they can index such a different amount of entries. |
|
That’s especially interesting since Safari history has been broken for a while. #1994 You might still have the old file laying around, which gets indexed by QS, but never updated by Safari. I’d get rid of it, or disable the entry. 44,000+ items in the catalog definitely explains your problem. I suspect the reason there are more rankings in the sample is that they take so much longer to run and are more likely to be observed/recorded. |
|
I was not doing anything specific around clearing caches between switching versions. By removing the old safari history file has made 1.3.2 as performant at 1.2.2. thanks for the help. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm not sure what happened in the last release, but quicksilver has been hanging since the last update. It's often non-responsive for a few seconds at a time. It might not seem like much, but when the benefit of quicksilver is that it saves me so many seconds, it really adds up!
What can I provide to help with the issue?
The text was updated successfully, but these errors were encountered: