-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
One report of a runaway RegOpen/Query loop #7748
Comments
I'm not so sure about that RegOpen/Query thing. WT seems to do that a lot and I'm not very good at interpreting what ProcessMonitor is showing. This thread is probably not aptly titled. One thing is for sure, opening and closing split panes ups the subsequent CPU use. You need some sort of tool to see this. One way is with ProcessExplorer. Start WT and ProcessExplorer. In ProcessExplorer, open WindowsTerminal.exe, go to the "Threads" tab and watch WT's main thread (here that's WindowsTerminal.exe+0x12AD0). After startup and settledown, and while idling, "CyclesDelta" is in the neighborhood of 10,000,000 (here anyway). Now open and close a split pane 5 times (close it with the "exit" command). Here, "CyclesDelta" (idling) is now in the 50,000,000 range. Open/close 5 more. "CyclesDelta" is now in the 100,000,000 range. If you can automate the opening/closing of split panes you can get more get striking results. I've had TaskMgr showing a constant 4% CPU for an idling WT. |
This is weird! We don't actually use those anywhere in Terminal, directly, so this smells like a framework issue. I can't explain why the system would be querying for display scaling every .03 seconds. |
As I said I'm not sure the increase in CPU use is related to the registry thing (see my second post). Maybe when the buffer is too small it's increased only modestly ... try again ... increase again ... try again ... until it works. That's what my pic might be showing. That sort of thing also seems to happen with other registry queries. But there's definitely increased CPU usage AFTER opening and closing a split pane. You only have to do a few to see a difference. If you have ProcessExplorer, try my experiment. There's a small memory leak too but that's harder to detect. |
To be fair, I'm responding to the issue you reported and put in the title 😉 |
Yes I realize that. And I admitted earlier that the thread may not be aptly titled. |
This appears to be the same issue as #8625. It does not seem to be related to any Reg* loop. |
Oh, I see. Thanks for identifying the duplicate -- you can tell how far back I am in triaging. /dup #8625. |
Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report! |
Environment
Microsoft Windows 10 Pro for Workstations
10.0.18363.1082 (1909)
WindowsTerminalPreview_1.4.2652.0_x64
Steps to reproduce
Expected behavior
Actual behavior
Right now WT has one tab, one pane, and one command processor idling. It's using about 3.5 seconds of CPU (kernel + user) every minute, by far the busiest process I have after for "System Idle Process". ProcessExplorer is monitoring all categories and reporting over 100 events per second. They look like this.
The text was updated successfully, but these errors were encountered: