Maxx CPU Usage.

[AJolly]

Flight Check

• I'm sure existing (open and closed) don't have duplicates
• I've tried reinstalling PT, Everything, EverythingPT

Describe the bug
Some searches max out my CPU.
I'll execute a search via power toys run, however it peers that its continuing to send queries to everything in the background even after the power toys run window has closed.

Logs (please upload or provide link to you log):
2024-12-18.txt
Everything Debug Log CPU.txt

Version:

• PowerToy: 0.87
• Everything: 1.5.0.1383a (x64)
• EverythingPT: 0.87.0.0
• Windows: Edition Windows 11 Enterprise
  Version 23H2
  Installed on ‎4/‎22/‎2024
  OS build 22631.3447
  Experience Windows Feature Experience Pack 1000.22688.1000.0

Installation method (How did you install the following softwares):

• PowerToys: Github

• Everything: manually

• EverythingPT: manually

Additional context
Log starting around lines 107222
ex:

2024-12-18 18:50:20.323: IPC: execute query: filter:ccdclauncher steam
2024-12-18 18:50:20.324: search 'filter:ccdclauncher steam' filter '' sort 5 ascending 0
2024-12-18 18:50:20.324: IPC: wait 2
2024-12-18 18:50:20.325: expanded:  <  < nofiltercase:filterpath:nofilterwholeword:nofilterdiacritics:nofilterprefix:nofiltersuffix:nofilterignorepunctuation:filterignorewhitespace:nofilterregex:< c:\ccdc\portableapps|c:\ccdc\scripts|c:\ccdc\sysinternals|c:\ccdc\avalerts\nirsoft|c:\ccdc\commandlinetools|<c:\users\jolly "start menu">|"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\"|"C:\Users\jolly\Downloads" ext:exe;lnk;cmd;bat;ahk !sync-conflict >  >  >  steam
2024-12-18 18:50:20.325: fast path search c:
2024-12-18 18:50:20.325: fast path search ccdc
2024-12-18 18:50:20.325: fast path search portableapps
2024-12-18 18:50:20.325: fast path search c:
2024-12-18 18:50:20.325: fast path search ccdc
2024-12-18 18:50:20.325: fast path search portableapps
2024-12-18 18:50:20.325: fast path search c:
2024-12-18 18:50:20.325: fast path search ccdc
2024-12-18 18:50:20.325: fast path search scripts
2024-12-18 18:50:20.325: fast path search c:
2024-12-18 18:50:20.325: fast path search ccdc
2024-12-18 18:50:20.325: fast path search scripts
2024-12-18 18:50:20.325: fast path search c:
2024-12-18 18:50:20.325: fast path search ccdc
2024-12-18 18:50:20.325: fast path search sysinternals
2024-12-18 18:50:20.325: fast path search c:
2024-12-18 18:50:20.325: fast path search ccdc
2024-12-18 18:50:20.326: fast path search sysinternals
2024-12-18 18:50:20.326: fast path search c:
2024-12-18 18:50:20.326: fast path search ccdc

I'm using the Everything filter ccdclauncher, which uses this filter

c:\ccdc\portableapps|c:\ccdc\scripts|c:\ccdc\sysinternals|c:\ccdc\avalerts\nirsoft|c:\ccdc\commandlinetools|<c:\users\jolly "start menu">|"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\"|"C:\Users\jolly\Downloads" ext:exe;lnk;cmd;bat;ahk !sync-conflict

[AJolly]

Upon further investigation it looks like part of the issue is the plugin will suddenly spam everything with a lot of past queries for some weird reason?

It also seems to do extra queries: Here I typed steam, it searched first steam, then s, then ste.

2024-12-18 19:08:51.083: search 'filter:ccdclauncher steam' filter '' sort 5 ascending 0
2024-12-18 19:08:55.540: search 'filter:ccdclauncher s' filter '' sort 5 ascending 0
2024-12-18 19:08:55.747: search 'filter:ccdclauncher ste' filter '' sort 5 ascending 0

[lin-ycv]

From what I'm seeing in the logs, this is the same issue as #137
For some reason you're getting null results
Result 5 is null for and/or , query: filter:ccdclauncher wmi
Which trips up the plugin and causes delays
PluginManager.QueryForPlugin Everything. Query cost - 3846 milliseconds
Based on you Everything debug log, I think the delay comes from EPT trying to parse a null value.
I've never been able to recreate a null situation, so I've never been able to solve. Previous poster said they solved it by changing sort method, which is weird.

Please set the sort to the same method in everything and EPT, then do a search and check if logs show null result, if it does please goto everything, find that result and lest me know what the filepath and filename for that result is.

[AJolly]

I figured out why it's sending all the old queries. Microsofts built in History plugin:

https://github.com/microsoft/PowerToys/blob/main/doc/devdocs/modules/launcher/plugins/history.md

"In order to make sure selected results in the history are still valid, we re-query the plugin the relevant plug using the PluginManager. If there are no results, this history item is not included. This usually means that the result is no longer valid. For instance, if a file was deleted, but it's still in the selected history we don't want to show it as a selectable result.

Because the results from the History Plugin are actually created from calls to the PluginManager, they will be exactly the same is if they did not come from the History Plugin."

I'm not sure if there is a way to filter these out via EPT. Or cache results that were used?

Also void suggests: "-Place your search before the filter:ccdclauncher term.
For example:
memory filter:ccdclauncher
"

unsure what the difference would be though, but we should probably consider changing that for future versions.

Void also suggested a number Of updates to my filter, and I'll see if null happens again after me making those changes.

"-use ext:exe;lnk;cmd;bat;ahk first as this will reduce the number of path lookups.

-Add a trailing \ to your paths
This will improve search performance.
The trailing slash causes Everything to match against a complete folder path."

[lin-ycv]

interesting discovery, I don't have history turned on, maybe that's why I'm not encounter these issues. I will need to find time to do some tests for compatibility with other plugins.

In theory this shouldn't create that much overhead.
Do you have include in global results option enabled for history plugin?
If yes, one way to test this theory would be to turn that option off, and see if it solves the CPU usage issue. If it's not included in the results, it's not doing the extra queries.

[AJolly]

The extra unrelated query issue definitely comes from the history plugin, and yes I had it with include in global results. It's a pity, since I found having the history included to be quite useful.

[lin-ycv]

I need to think about this, history invokes pluginManager to query EPT, which I believe is the same process for a normal query. So there's no simple way to filter out queries from history.
For now i think it's either have global results for history disabled, or I'd have to somehow code EPT so it's completely excluded from history.

[AJolly]

Does ept know if you take action on any of the results you send to power toys Run? If so, itd be possible to to create our own history cache in ept. Admittedly I care because I'm using ept to work around runs lack of configuration ability for defining what programs it finds for the built-in launcher. And in that context if I've clicked on an item before, I'm much more likely to want that same item again in the future.

…

On Sun, Dec 22, 2024, 4:58 AM Lin Yu-Chieh (Victor) < ***@***.***> wrote: I need to think about this, history invokes pluginManager to query EPT, which I believe is the same process for a normal query. So there's no simple way to filter out queries from history. For now i think it's either have global results for history disabled, or I'd have to somehow code EPT so it's completely excluded from history. — Reply to this email directly, view it on GitHub <#149 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAWKZM2HLSVO6DEW2MQRWL2G2LPDAVCNFSM6AAAAABT33QQZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYGQYTKMRYGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[lin-ycv]

if I've clicked on an item before, I'm much more likely to want that same item again

In this case, maybe the easiest solution is for you to set the sort method to RUN_COUNT_DESCENDING? If you enable run count in Everything, then each time you execute a result, the tally increases, and we can sort the result based on the tally.

EPT itself doesn't keep track of what's being executed. I could create a history cache in the callback, but I think Everything's run count already suffices?

[AJolly]

In this case, maybe the easiest solution is for you to set the sort method to RUN_COUNT_DESCENDING? If you enable run count in Everything, then each time you execute a result, the tally increases, and we can sort the result based on the tally.

Thats a pretty good idea, I'll try that for a while.

For the history query issue, it Might be worth seeing how their own program or window search plugins interact with history, or are they also rerunning all their queries?

[lin-ycv]

from what i can tell, they just accept the new query:

"Because the results from the History Plugin are actually created from calls to the PluginManager, they will be exactly the same is if they did not come from the History Plugin."

so there's no way to handle it differently. The only way i can think of to differentiate it is to do a stackTrace, but that would impact the performance negatively.
I think it's more apparent on your machine because your search is more complex.