Skip to content
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

Performance regression on auto-complete #1417

Closed
ronan36880 opened this issue Nov 18, 2024 · 3 comments
Closed

Performance regression on auto-complete #1417

ronan36880 opened this issue Nov 18, 2024 · 3 comments

Comments

@ronan36880
Copy link
Contributor

Commit 1c5e832, which was created created to address #1294 seems to have caused a performance regression on auto-completion (I have confirmed with a git bisect).

I don't fully understand what is going wrong here, but here's the completion file I am using:
fluffyrock-unbound-tag-completion.csv

Replication steps:

  1. Enable the fluffyrock-unbound-tag-completion completion file in the settings.
  2. Open a prompt, type by and press space.

It will then take some time to process things:

krita_2024-11-18_12-49-59.mp4

Locally reverting this commit seems to have fixed the issue - I wonder if the lstrip function could be much more computationally intensive than expected?

@Acly
Copy link
Owner

Acly commented Nov 18, 2024

I don't think it has anything to directly with lstrip.

Previously by was stripped to by which is < 3 characters and does not trigger completion
After the change, it triggers completion for by , which matches a LOT of tags (I think). Much more than any other 3-letter prefix. And it's just slow because it's a lot.

@ronan36880
Copy link
Contributor Author

I don't think it has anything to directly with lstrip.

Previously by was stripped to by which is < 3 characters and does not trigger completion After the change, it triggers completion for by , which matches a LOT of tags (I think). Much more than any other 3-letter prefix. And it's just slow because it's a lot.

Oooh, that's interesting. It does match a lot of tags from a quick look through the csv file.
What would be the best way to fix it? It does freeze the UI thread every time after the change.

One obviously workaround would be to edit the csv file, but I'd rather avoid that if possible 😅

@Acly
Copy link
Owner

Acly commented Nov 18, 2024

I think sorting and cutting off the csv is not a bad idea in general (not by hand obviously) - the tags with low use-count won't work anyway. Not sure if that throws out enough of the by matches though, but it doesn't seem to be a problem for the existing sets which include similar tags.

Don't have a great idea how to fix it in code. Could start auto-complete only at the 4th character, but that makes it less useful. Or special case the by prefix, or a bit more generally anything with a trailing space perhaps...

Acly added a commit that referenced this issue Nov 29, 2024
@Acly Acly closed this as completed Nov 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants