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

Slow performance with very long lines #39

Closed
minad opened this issue Feb 15, 2021 · 6 comments
Closed

Slow performance with very long lines #39

minad opened this issue Feb 15, 2021 · 6 comments

Comments

@minad
Copy link
Collaborator

minad commented Feb 15, 2021

To keep in mind, see radian-software/selectrum#436 (comment). Maybe nothing can be done for certain patterns which may necessarily result in high complexity. Needs further investigation.

@oantolin
Copy link
Owner

oantolin commented Feb 15, 2021

One good test to try would be to test (setq completion-style '(orderless) orderless-matching-styles '(orderless-flex)) vs (setq completion-styles '(flex)). If, as I suspect, they are comparably slow, it would be an indication that there isn't much to be done about this.

I wasn't fully aware of my motivation at the time, but in my personal configuration the expensive styles like initialism and flex are always introduced by explicit syntax. It must have been that I felt those were slower (but I never deal with long lines, so the difference is pretty small).

@minad
Copy link
Collaborator Author

minad commented Feb 15, 2021

I am not using flex by default since it seems so much more expensive. It always leads to a noticeable slowdown. But initialism is activated always. I am using the default settings with the explicit syntax for flex~ and literal= and !negated literal.

@oantolin
Copy link
Owner

My syntax for flex even has two characters! Again, probably subconsciously I felt it was even slower than initialism. I use a single (either leading or trailing) . for initialisms but curly braces for flex (I also use electric-pair-mode so I only type one brace).

@minad
Copy link
Collaborator Author

minad commented Feb 15, 2021

It is not unreasonable to use multiple characters for the explicit styles in order to avoid interference with regexps. And usually when I do an explicit style switching, typing two letters wouldn't make a difference.

@minad
Copy link
Collaborator Author

minad commented Mar 23, 2021

Just stumbled over this: https://github.com/doyensec/regexploit 😆

@minad
Copy link
Collaborator Author

minad commented May 7, 2021

What about removing initialism from orderless by default? Instead recommend creating special orderless-styles which include more matching styles? And in any case we have the matching style dispatchers.

(orderless-define-completion-style orderless+initialism
  (orderless-matching-styles '(orderless-initialism orderless-literal orderless-regexp)))

(setq orderless-matching-styles '(orderless-literal orderless-regexp))

(setq completion-category-overrides
      '((file (styles partial-completion orderless+initialism))
        (command (styles orderless+initialism))
        (buffer (styles orderless+initialism))
        (consult-multi (styles orderless+initialism))
        (symbol (styles orderless+initialism))))

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