High CPU load when searching for /.+.+aa/ regex

Found a bug in "Everything"? report it here
Post Reply
MrCricket
Posts: 2
Joined: Tue Aug 31, 2021 5:10 pm

High CPU load when searching for /.+.+aa/ regex

Post by MrCricket »

Hi,

The App looks stuck with 100% cpu load (8 cores) when searching for this (bad?) regex:

Code: Select all

.+.+aa
It this expected?

My Search settings are
  • Match Path
  • Enable Regex
  • Everything
void
Developer
Posts: 16773
Joined: Fri Oct 16, 2009 11:31 pm

Re: High CPU load when searching for /.+.+aa/ regex

Post by void »

This is expected.

The two .+ patterns are a recursive nightmare.
Additional .+ patterns exacerbates the issue.


For improved performance, minimize the number of * modifiers or use a literal pattern between the two * modifiers.
For the same results, please try the following search:

..aa

Regex matches anywhere in the text, to match from the start of the text:
^...*aa


A similar issue with wildcards:

*?*?*aa*
MrCricket
Posts: 2
Joined: Tue Aug 31, 2021 5:10 pm

Re: High CPU load when searching for /.+.+aa/ regex

Post by MrCricket »

void wrote: Tue Aug 31, 2021 11:44 pm The two .+ patterns are a recursive nightmare.
Additional .+ patterns exacerbates the issue.
right - it was a misprint, I meant /.+aa/
void wrote: Tue Aug 31, 2021 11:44 pm This is expected.
I think it would be great if the App could detect such cases proposing to cancel the search after some time (10 seconds? can be optional/configurable in Settings)

Thanks!
void
Developer
Posts: 16773
Joined: Fri Oct 16, 2009 11:31 pm

Re: High CPU load when searching for /.+.+aa/ regex

Post by void »

right - it was a misprint, I meant /.+aa/
path:regex:.+aa

is still quite slow because Everything will attempt to find the regex pattern anywhere in the filename.
(it's still a recursive nightmare)

path:regex:.aa would produce the same results much faster.


Maybe Everything could look at optimizing .+aa to .aa or ^.+aa
Although, .aa would affect highlighting.
I think it would be great if the App could detect such cases proposing to cancel the search after some time (10 seconds? can be optional/configurable in Settings)
I will consider an option to do this.
Thank you for the suggestion.

For now, the search can be cancelled by:
  • Clearing the search box.
  • Typing in a new search.
Marco Polo
Posts: 11
Joined: Mon May 16, 2022 5:40 pm

Re: High CPU load when searching for /.+.+aa/ regex

Post by Marco Polo »

void wrote: Thu Sep 02, 2021 10:19 am path:regex:.aa would produce the same results much faster.

Maybe Everything could look at optimizing .+aa to .aa or ^.+aa
Although, .aa would affect highlighting.
@MrCricket
Try non-greedy search - path:regex:.+?aa will have less performance impact. And it will have less highlighting affect - highlighting will be almost exact the same as with .+aa greedy search. Highlighting result will be the same in many (most ?) cases.

@void
As an option `everything` can block search and replace greedy patterns with non-greedy ones. In this case user input .+aa will be replaced with .+?aa and the user should select whether agree with wizard-adviced regexp or continue with greedy search. User should have the choice because non-greedy regexp is not exactly the same (in this case for highlighting, but the searches could be performed in file text and they will be more complex) so that user might be disappointed with silent transformation that breaks search.
void
Developer
Posts: 16773
Joined: Fri Oct 16, 2009 11:31 pm

Re: High CPU load when searching for /.+.+aa/ regex

Post by void »

@void
As an option `everything` can block search and replace greedy patterns with non-greedy ones. In this case user input .+aa will be replaced with .+?aa and the user should select whether agree with wizard-adviced regexp or continue with greedy search. User should have the choice because non-greedy regexp is not exactly the same (in this case for highlighting, but the searches could be performed in file text and they will be more complex) so that user might be disappointed with silent transformation that breaks search.
Everything already tries to optimize some search patterns.

For example:
regex:\.foo$
is replaced with:
diacritics:endwith:.foo



I will consider replacing .+aa with .+?aa
Thanks for the suggestion.


These optimizations can be disabled with the regex_optimization ini setting.
Post Reply