High CPU usage

[georgearoush]

Hi,

I'm using TCC 22.00.43 x64 Windows 10 [Version 10.0.17763]

When I start TCC, CPU utilization spikes to 10-15 % and stays there. After about 4 hours of usage, opening new shell, closing existing ones, running generic DOS commands, etc. (I don't use any of TCC's speciall commands) the CPU utilization spikes to 20-25% and will stay there. Once I close TCC, CPU utilization goes back to 1-2%.

At any given time, I have no more than 5 shells open concurrently and I do not have any background applications running in any of the shells. Can you help me identify why this is occurring?

Thanks,

-- George

 

[rconn]

TCC doesn't have any background threads doing any heavy processing.

Almost all of the cases like this end up being due to a third-party app that has injected code into TCC. (AV apps & screen managers are notorious for doing this.)

Does Task Manager say that TCC is using the CPU?

 

[AnrDaemon]

If you can reproduce it with v24, …

 

[georgearoush]

Hi,

This issue continues to hunt me. Attached are screenshot of the CPU utilization by TCC 22.00.43 x64. I have screenshots with 4, 3, 2 and 1 TCC shells open. As you can see, the less shells I have open the CPU utilization goes down. At 4 shell, the CPU utilization is between 19-23%, at 3 it is between 15-17%, at 2 it is between 5-8%, and at 1 it is between 2-5%.

There is no issue when I first start TCC, even when have 10 shells open. The issue seems to build up over time after few hours. This has been a continues pattern. How can I debug what's causing this issue?

Thanks,

-- George

 

[georgearoush]

Here is an experimenter that I did.

1) I closed my TCC as such there were no TCC running any more.
2) I started a new TCC and let it sit as-is (I didn't use it at all) for 1 hour.
3) When I first started TCC, its CPU usage was 1-2%, but after 1 hour, its CPU usage is between 7-10% constantly. See the screenshot for details.

 

[rconn]

If you have any screen managers or AV, try disabling them temporarily (they're notorious for injecting code into other apps).

There isn't anything in TCMD or TCC that should be doing this - I typically have a TCMD session with several tabs open for days, and don't see any increased CPU usage.

 

[georgearoush]

Hi,

@rconn, I do not have AV on this system other than Windows Defender. And to eliminate WD, I disabled it and still see the same issue. As for screen savor, I disabled that and it didn't help.

From the screenshots I shared, you can see a "Console Window Host" is spawned per TCC and it is each "Console Window Host" taking a % of CPU. That as well as "Administration: TC 22" is taking a good % of CPU. Those 2 together are what causing this high CPU. Given this, the questions I have are:

1) Why is a "Console Window Host" started per TCC and what is "Console Window Host" doing to take CPU cycles?
2) What is "Administration: TC 22" doing to take CPU cycles?

As an added bonus, I un-installed and re-installed TC but that didn't change anything.

I need instructions to debug this issue and with your help I'm willing to experiment. As is, TC is taking away 25% of my CPU cycle, constantly.

Thanks,

-- George

 

[Charles Dye]

1) Why is a "Console Window Host" started per TCC and what is "Console Window Host" doing to take CPU cycles?

"Console Window Host" is the component of Windows which is responsible for console windows. It's used by CMD.EXE and other console programs too. Do you have the same issue running CMD.EXE for long periods of time?

 

[georgearoush]

@charles, no, I do not see this issue with CMD.EXE. In fact I have 4 of them which were started Monday of last week (12 days now) and all show 0% at this moment. Here is a screenshot.

 

[rconn]

1) Why is a "Console Window Host" started per TCC and what is "Console Window Host" doing to take CPU cycles?
2) What is "Administration: TC 22" doing to take CPU cycles?

1. It's the other way around - "Console Window Host" is the Windows component that starts TCC (and every other console app). You'll have to ask Microsoft what it's doing to use so much CPU time on your system.
2. Take Command ("TC Administrator") uses a small amount of CPU to scan the hidden console windows and display them as tab windows.

 

[georgearoush]

@rconn:

> You'll have to ask Microsoft what it's doing to use so much CPU time on your system.
I can ask MS, but they will point me to the screenshot that I already showed you above, in which CMD.EXE also has "Console Window Host" and it is using 0% CPU.

> 2. Take Command ("TC Administrator") uses a small amount of CPU to scan the hidden console windows
As I have shown in my screenshots, constantly using 2-4%, 24x7 when there is nothing running in TC is not a small amount of CPU. Can it be that TC's constant use of CPU leading to the issue in "Console Window Host"? How can I stop TC from doing this background task?

 

[rconn]

Take Command normally uses < 1% of CPU unless you've got a *lot* of screen activity going on.

Take Command does call console APIs (handled by conhost) to read the screen buffers, but unless you've got an extremely slow machine it won't use a noticeable amount of CPU.

If you open a TCC stand-alone console window (i.e., not a Take Command tab window) do you see the same issue w/conhost?

Do you have ANSI enabled in the TCC window?

 

[georgearoush]

@rconn, I think we are getting somewhere now and maybe even narrow down where to look. Here is what I did.

1) Closed TC 22 as such I have no JPSoft application running.

2) I started TCC stand alone and after waiting some 30 min, the CPU never went over 0%. Here is a screenshot (as you will see "Console Window Host" is using 0%):

3) I started TC 22 and as soon as it started, it was using at least 8% CPU. Here is a screenshot (as you will see "Console Window Host" is using 5% and TC 22 is using 3%):

4) Next I attached the stand alone TCC to TC 22 via "Attach Tabs" menu option and now "Console Window Host" of the stand alone TCC end up using CPU cycles out of no where. See screenshot:

So, I suspect whatever TC 22 is doing, it is causing the continues CPU usage for "Console Window Host"

 

[georgearoush]

@rconn,

Regarding your question of:

> Do you have ANSI enabled in the TCC window?

No I don't. Here is a screenshot:

However, I do have TCMD.INI file which among other things it has "ColorDir" key in which I use to color code files for DIR usage. I'm attaching it here in case it matters for this issue.

 

[georgearoush]

OK. I found a use-case that will cause the CPU issue, but it is very puzzling. Maybe someone from JPS can see through this.

I always start TC in "Maximize" mode and always have been, take the full screen on my monitor. If I resize the TC window so it takes about 2/3 of my screen, the CPU usage will drop down to 0% or around 1%. If I keep resizing it so it takes more and more of the screen area, the CPU usage will go back up to that 10% and more. If TC windows was in "Maximize" mode and I hide it behind another application or click on the "Minimize" icon, for both cases, the CPU remains at that 10% or more mode. Thus, the only time the CPU is at 0% or around 1% is when TC is less than about 2/3 of my screen size.

Does this window sizing of TC application and CPU usage make any sense leading to this issue? This is very odd but It's a use-case I can easily reproduce and demonstrate.

 

[georgearoush]

Can anyone from JPSoft shed some light on this issue? If you need any data from me, let me know.

-- George

 

[Charles G]

Can anyone from JPSoft shed some light on this issue? If you need any data from me, let me know.

-- George

You might need to @rconn for Rex to see this thread......

 

[rconn]

The larger your (hidden) console windows, the more api calls TCMD has to make to conhost.

On my 3 year old laptop with an external monitor, a maximized window (476x175) with 3 tabs uses about 5%. My two year old desktop uses 1 or 2%.

A minimized TCMD window shouldn't use any cpu.

 

[georgearoush]

@rconn,

> The larger your (hidden) console windows, the more api calls TCMD has to make to conhost.

This doesn't make any sense! to me Why would TCMD will need to make more / less API calls to conhost based on its window size?! What are those API calls that TCMD is making?

Are you telling me I should not use TCMD at full screen size of my monitor if I don't want it to drain down my laptop battery?

> A minimized TCMD window shouldn't use any cpu.

Well, that is defiantly not the case here and a minimized TCMD window is useless.

 

[georgearoush]

@rconn,

> On my 3 year old laptop with an external monitor, a maximized window (476x175) with 3 tabs uses about 5%. My two year old desktop uses 1 or 2%.

So you see this behavior in your env too, thus we now have a confirmation of this issue in your env. as well. But for me, it is always at 20% or more as I have shown above. This is not acceptable, even at 5%.

 

[rconn]

TANSTAAFL.

TCMD has to continually query the hidden console windows to get their screen buffers and compare them with the previous ones to see if anything changed. If you have a large console window, that takes longer than reading and comparing a small window. If you have a slow machine and/ or video card, it takes longer.

It is a balance between performance and CPU usage. TCMD could query the consoles less often, at the cost of a stuttering display & slower output. Conemu uses about the same CPU as TCMD and is about 30% slower. The new Windows Terminal alpha uses 1 or 2% less, and is 50% slower.

If you insist on maximizing your window and don't want to give up even 5%, your only option is to stick with standalone console sessions. Which will be much slower, but which will consume the minimal amount of CPU when sitting at the prompt.

 

[georgearoush]

@rconn,

In my case, the CPU utilization is always and is constantly at and over 20%. That's no small amount at all. And I'm running on a very decent hardware (see screenshot below) in which my laptop is only 2 years old.

It is not clear to me what you mean by "TCMD has to continually query the hidden console windows to get their screen buffers ..." can you please explain what this means?

> If you insist on maximizing your window and don't want to give up even 5%, your only option is to stick with standalone console

How do I set this? I need to try it and see what's the impact. As is, I cannot afford TCMD constantly consuming 20% and up of my CPU cycles and draining my laptop battery needlessly even when I'm not actively using TCMD.

-- George

 

[rconn]

It is fundamentally impossible for a GUI app (like Take Command, ConEmu, etc.) to run console apps in tab windows. So they have to resort to some smoke and mirrors to do it. It is necessary to start the console apps hidden, and then do some type of "screen scraping" to display the contents in a tab window.

There are two ways to do this:

1) Inject code into the console app, which reads its screen buffer, and sends any changes to the GUI tab window app (using pipes or shared memory). This is what ConEmu and a few others do; it has somewhat lower overhead but a couple of severe disadvantages: some AV's consider this behavior to be malware and will try to block it, and the injected code has to be compatible with every console app in existence (which will never happen - so you aim for the majority of common apps).

2) The GUI app attaches itself to the hidden console's screen buffer, and reads that buffer periodically (as in every 30-40ms) looking for changes. This is what TCMD does; the advantage is the display output speed is considerably faster; its disadvantage is there's no way for TCMD to know whether the console app is actually doing anything, so most of the reads & compares don't find any changes.

With both approaches, the bigger the screen buffer, the more overhead there is communicating between the hidden console & the GUI tab window.

If you don't need any of the GUI features, you can simply run the console app (TCC.EXE, CMD.EXE, etc.) in a console window, and maximize that window. The console app won't need to communicate with a GUI tab window app, so the overhead will be as small as it gets.

 

[georgearoush]

@rconn, when you say "reads that buffer periodically" does that mean if the console buffer is smaller (not the window size) that will help consume less CPU?

 

[georgearoush]

@rconn, also, why isn't TC GUI app smart enough to detect that it is minimized and thus won't have to scan the buffer to take CPU cycles? Or that it only needs to scan the active tab's buffer vs. all tabs'? In my case, the CPU usage goes up as I add more tabs or the window is minimized or is behind other windows (completely invisible).

 

[rconn]

@rconn, when you say "reads that buffer periodically" does that mean if the console buffer is smaller (not the window size) that will help consume less CPU?

No, it's only the window size that's relevant.

 

[georgearoush]

No, it's only the window size that's relevant.

@rconn, If it is just the window size, why would TC be doing any kind of processing when the TC window is hidden, such as completely minimized or hidden behind other windows?

I'm not ready to give up on this without fully understanding the issue and I think there is a defect here to be addressed. My motivation is the high CPU usage is not only taking away cycles from other applications, but it is also shortening the life of my battery recharge need.

 

[rconn]

There *is* a bug in the code to detect whether the window is minimized (a recent RTL update is broken). I have fixed that for the next build. Hidden behind another window is another matter, and the Windows APIs do not tell me whether the TC window is hidden behind another window, only that the TC window has the visible attribute set.

The cpu usage when you have multiple tab windows is unavoidable - I cannot disable updating everything except the current window without breaking tab groups & splitter windows. (Well, maybe I can, but it's going to involve some significant changes to Microsoft's code. Maybe in a future version.)