-
Notifications
You must be signed in to change notification settings - Fork 794
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Search results are slow to appear #523
Comments
Hopefully, #460 addresses the problem. While not the perfect solution, it makes search faster by running it in the multiple threads, and utilising additional caching. The change should make it into 0.3.0. |
Good to hear. :) Do you mind if I keep this open until I get a chance to try 0.3.0? |
There were numerous improvements in the search and general performance. Please give a freshly built Zeal a try. I am closing this in favour of #265 to keep all search performance issues in one place. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for a related request. |
While #265 seems to be about the GUI lagging while typing, I have a different "slow search" problem.
While I don't have a problem with GUI lag, I have 83 docsets installed and, even when using a prefix like
css:
, I find it can take several seconds for search results to appear. (I suspect this to be a combination of find-as-you-type and my use of a traditional 7200rpm rotating rust hard drive.)I'm not sure how much can be done, but I thought I'd bring it up. (Might it help to add a checkbox for slow systems which defers the find-as-you-type until the lesser of X characters or Y seconds has passed to make effective use of the SQLite indexes, then filters within the in-memory results as more characters arrive?)
The text was updated successfully, but these errors were encountered: