High CPU usage while typing

[IronicChloride]

HexChat 2.9.6.1 (build date: 2013-09-15, both x86 and x64 non-portable builds, clean install of x64 build and then x86 to see if it makes a difference).
OS: Windows 8.1 64-bit
The CPU is quad core i5-4570. When idle, the CPU runs at ~800MHz. Fast typing in a message box causes the frequency to rise up to ~3 GHz, and the CPU usage in this state is up to 20% (total of all cores). One of the cores is being loaded up to 80% (with some core switching). Slower typing causes less CPU load (on average). The power consumption rises from ~28W to more than 40W (I have a watt meter plugged in).

Sometimes the CPU load stays that high after I had finished typing, and drops back to normal only after I switch to another window.
No suspicious activity found with Sysinternals Process Monitor (disk writes, sockets, registry, etc.). No visible changes in memory usage while typing.

The CPU load is caused by a key release event. When I hold down a key, the CPU usage stays low until I release it. Releasing a key adds about 0.5 seconds to the "CPU user time" performance counter of the process.
I think it may have something to do with GTK+'s crappy keyboard handling. There's no information on the GTK+ version in Help->About window.

[TingPing]

Spellcheck enabled?

[IronicChloride]

Spell checking is disabled. Turning it on and off doesn't make a difference.

[Arnavion]

Does Task Manager report HC using more CPU time during that?

Regarding the GTK version, we know what version it is since we build it ourselves (it's 2.24.19)

[IronicChloride]

If you mean while switching the spell checker, then there is a small peak, but a very brief one. Turning the spell checker on adds about 0.05 s to CPU user time, turning off about adds ~0.08 s.
I've just realised, I haven't had any dictionary installed previously, however after doing so (and restarting HC, just to be sure) the problem is still there. There's no difference in CPU load with and without spell checker enabled.

One more thing I found: Holding down any of the modifier keys (shift, ctrl, alt) causes HC to fully occupy one of the CPU cores. Pressing down another modifier key does nothing (the CPU usage is still high), but when that key is released, the CPU load drops. If however the first key is released (while the second one is still being pressed), there's only a short drop of CPU load, and it backs up to full load once again.
If the second key (the first one still being a modifier key) is a one that has the auto repeat feature turned on (like alphanumeric keys), then the CPU usage drops after that key is pressed (or more likely, when the OS sends a key release event for that key). If the second key has no auto repeat (function keys, home, end, etc.) or it is any of the cursor keys (I've thought that these are auto repeat keys), then the CPU usage stays high until that key is released.
It seemed to me like it's a nasty race condition, however setting processor affinity for HC to a single core doesn't change anything. The other thing I suspect is bad handling of a key release event, like busy loop waiting for release after a key press event.
I have checked the same version of HC on an Intel Atom N450 netbook (single core with Hyper Threading, Win 7 Starter), and this issue doesn't exist.

[Arnavion]

If you mean while switching the spell checker

I meant when releasing a key, since that is when you said your CPU activity peeks in the OP.

One more thing I found: Holding down any of the modifier keys (shift, ctrl, alt) causes HC to fully occupy one of the CPU cores

Is the rest of your post starting from this line with spellcheck enabled? I cannot repro any of it without spellcheck. If so, can you see if you still repro with spellcheck disabled?

[IronicChloride]

It happens with and without spell checking.
I would say that it's related to keyboard handling, however if you say, that you can reproduce this issue with spell checking enabled, I'm becoming to think once again about a race condition. The spell checking might introduce some small delay which is enough to prevent the race condition on your CPU. On the netbook I've mentioned before the issue doesn't exist at all, no matter what the settings are.

[TingPing]

@shogoonn the only performance issue I have ever seen is when spell check is used on massive words (100s of chars). That is the only reason I brought it up and is unrelated.

[Arnavion]

if you say, that you can reproduce this issue with spell checking enabled

I didn't say that.

[JOHW85]

I too have this problem. Spell check being enabled or not does not seem to remove the bug.

[IronicChloride]

I've just got a new HexChat version (2.10.0 x64) and the issue is still there.
The CPU load while typing seems to be a bit lighter (about 16% total @ 2 GHz). The CPU does not scale its frequency up to a maximum. There is almost no load when a single alphanumeric key is being held down. The behaviour, which I've described earlier still persists.
One curious thing I've found, is that when I delete a string of characters from the beginning (holding down the "Delete" key), the CPU usage (or rather a single core) spikes to 100%. However, when I do so from the end (by holding down "Backspace"), the CPU usage stays flat.
Moving the cursor left and right with cursor keys (or actually just holding down those keys) also causes high CPU load.
In this version the full load is being taken by a single core (no load is shared between cores).

@CKtalon What hardware are you running HC on?

[JOHW85]

Intel i5 [email protected]

[IronicChloride]

Maybe it is a race condition then, one that shows up only on some recent faster CPU's.

[jackpoz]

spell check disabled, using HexChat 2.10.0 on Windows 8.1 Update 1 x64 on Intel i5 @ 3.70 GHz 4 threads. not using any custom script.
that 10% means it's using almost half core just to keep up with me typing a normal sentence with normal speed

[Lunatrius]

Happens when you hold down CTRL, ALT or SHIFT.

[jackpoz]

Visual Studio profiling using 8f9ed6d version. I was holding the CTRL key in the highlighted part and writing the alphabet before that

Platform is Windows 8.1 Update 1 x64 on Intel i5 @ 3.70 GHz 4 threads , you can notice how it uses over 20% CPU so almost a whole core.
It actually happens even in the User Information startup screen before HexChat even connects to any server.

Please remove the "unconfirmed" label to the issue.

[Arnavion]

@jackpoz Since you know what you're doing, get the PDBs for the GTK bundle (ask tomek in #hexchat) and give us the callstack too.

[jackpoz]

I did another profiling session keeping pressed the CTRL key, releasing it for few seconds, then writing ~1 character a second in the "Nick name" popup window without connecting to any server.

You can notice the 2 session spikes in the graph below

57% of the CPU usage happened in the poll_rest() function of glib, gpoll.c file line 132

The nature of Visual Studio profiling doesn't show a single callstack, rather it shows the Inclusive/Exclusive % spent in each function

[Arnavion]

You should definitely be able to get a list of callers going back all the way to hexchat code. That is what I meant by call stack.

Also https://mail.gnome.org/archives/libsoup-list/2009-December/msg00010.html and misc google results for "g_poll" high cpu usage

[jackpoz]

here's the callstack going back from that poll_rest():

poll_rest() at glib\gpoll.c L152
g_poll() at glib\gpoll.c L315
g_main_context_poll() at glib\gmain.c L4028
g_main_context_iterate() at glib\gmain.c L3729
g_main_loop_run() at glib\gmain.c L3928
gtk_main() at gtk\gtkmain.c L1257
fe_main() at fe-gtl\fe-gtk.c L320
main() at common\hexchat.c L1111

[jackpoz]

can we at least get this issue "confirmed" instead of leaving it with "unconfirmed" label ?

[jackpoz]

this issue is now 1 year old, is there any plan about how to tackle it ?

[jackpoz]

Issue still happens using HexChat 2.10.2 x64 on Windows 8.1

[Warpten]

Just a heads up, I'm not noticing any issue on Win7, Hexchat 2.9.5 32bits. Might be interesting to bisect

[tahg]

Cannot confirm either, Win7 Hexchat 2.10.1. Seems like an issue exclusive to one or more versions of Windows 8.x

[MadClown]

I can confirm that this issue is happening on my computer also. My CPU usage did indeed jump up quite a bit from typing like how it was described by the OP. Typically CPU usage was about 10-15% when typing quickly and only happened when keys got released. Holding a key down did not increase CPU usage.

Windows 8.1
HexChat 2.11.0 x64 (spell check disabled)

[Warpten]

Upgraded to Win 8.1 x64, hexchat 2.10.2, successfully reproduced.

[LuqJensen]

Reproduced on win10 x64 using hechat 2.10.2

[Arnavion]

• Test builds use whatever GTK is mentioned in (Tracking) Latest versions gtk-win32#10 which at the moment is latest
• Your call stack shows GTK spending time in the code it constantly calls anyway (polling for new events). The reason why it's polling so much that it's pegging a core to max is unknown.
• I don't see I said it before in this thread, so try with 32-bit build. I see atleast one user says they could not repro with 32-bit build.

[genbtc]

Reproduced on Hexchat 2.10.2 x64 on windows 10. (the hexchat about box says "Windows 8")
On a hyperthreaded quadcore I7, its using 11% total CPU, (over 40% on 1 core).
Please people fix this. I do not have time to be recompiling hexchat fiddling with GTK libraries I know nothing about.

[Arnavion]

@genbtc Read the comment directly before yours, especially the third point.

[jackpoz]

41% CPU usage pressing CTRL on "Nick name" using "HexChat 2.10.2 x86.exe" on WIndows 10 x64 with Intel i5 @ 3.70 GHz 4 threads

Is there any hexchat developer who uses Windows x64 ? Quite disappointed that no developer tested it in 1 month after @Arnavion asked to try the 32 bits version

[Arnavion]

It's unfortunate that the 32-bit version has the same issue.

Is there any hexchat developer who uses Windows x64 ?

Yes, but I use W7 which does not demonstrate this issue (as mentioned before in this thread). @tomek You're on 8.1?

[genbtc]

X86 version totally does it too: http://puu.sh/k5jGU/a7eac9d48f.png
Keep in mind 11-12% is one full core on a hyperthreaded quad i7. This percentage is in line with normally max 1 threaded operation.
And yes, It was fine on win7. I read somewhere that windows 8->10 has some kind of internal spell checker, and I tried to disable it with these registry keys:
[HKEY_CURRENT_USER\Software\Microsoft\TabletTip\1.7]
"EnableAutocorrection"=dword:00000000
"EnableSpellchecking"=dword:00000000

But my computer has all the "tablet" shit explicitly disabled on purpose, and this did not fix it.

[TingPing]

I read somewhere that windows 8->10 has some kind of internal spell checker

Windows 8 added spell checking and HexChat < 2.11.0 never made use of it.

[Mo0NTan]

I just discovered a way to dramatically decrease the CPU usage when typing, I disabled the Runtime broker in the task manager. This shuts off the built in windows 10 spell check in hexchat making every word have a red line under it, I then put my old windows 7 spellcheck enchant folder in my hexchat shared folder (i am using a portable install). This stopped the spell checker to not make red lines under every word.
I believe there is a registry hack to disable the Runtime broker permanently, but every time you re-open hexchat or any other program that depends on it the Runtime process restarts. I just disable it again. There is still a little cpu usage but not nearly as much as it did.

[Mo0NTan]

I forgot to add... You should wait like 5 minutes to really tell the difference after you disable it, I've also noticed if you disable Cortana along with the Runtime broker it is even better. but then Cortana kicks back in along with the Runtime broker in less then a minute, So for now i just keep the runtime broker disabled

[TingPing]

@Mo0NTan What version do you use? I already said "Windows 8 added spell checking and HexChat < 2.11.0 never made use of it.". Also does disabling it in Preferences > Input do nothing compared to this?

[genbtc]

@Mo0NTan Dude dont mess with runtimebroker...You disable it from PC Settings->Devices->Typing, and I checked on my system, closing runtimebroker did not help anything since I already had these off,, and I would never use Cortana .... :

[Mo0NTan]

oh, Thanks,That seems to work too, i did manage a hack to disable cortana, but that didn't significantly help at all, Seems the spellcheck does a bit. It goes to like 10 to 15% apposed to 30% and don't get stuck at 30. It could be video card driver related. I don't know?

[jackpoz]

The CPU usage issue affects only HexChat and not other applications like Notepad++, trying random things like killing Windows processes doesn't look much useful.

[Mo0NTan]

I wonder if an older version of hexchat regardless of the security holes wouldn't have this issue. I just realized how hot this is on my legs while on my laptop,

[jackpoz]

This issue is now 2 years old. In the meantime a new OS version came out (Windows 10) and still has the same issue.
If the root cause is in GTK+ then the issue should be reported to that project so they can fix it, there are already clear How To Reproduce steps

[genbtc]

Can one of us unofficially modify GTK and provide a diff patch so that we can share it amongst ourselves in the meantime ? I would gladly recompile it as a second person to test. Unless someone starts the ball rolling, and at least proves that modifying GTK can fix the issue and that theres no other way to fix hexchat's code itself, then I doubt the GTK people will admit theres a problem on their end and just push the blame back saying its hexchat's fault...
Edit: I managed to download the source for hexchat and compile it. The problem still exists. I wasn't able to modify anything yet (no clue how).
Note: I think it might warrant a note in the Developer Docs that "powershell.exe" has to be in your PATH variable, (mine somehow wasnt) and it was non-obvious until I opened up the "Output from build" tab in VS2015. End result, the PATH variable still wasnt enough and I had to modify these 3 files to get it to compile (cryptic error about not finding config.h. hexchat cannot open include file config.h) http://puu.sh/laxYG/d549bce49a.png

[TingPing]

@genbtc We already ship a few patches that never made it upstream, so if somebody solves this that would be acceptable.

[Arnavion]

I think it might warrant a note in the Developer Docs that "powershell.exe" has to be in your PATH variable

%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\ is in PATH on a default Windows install. It doesn't need to be mentioned in docs.

End result, the PATH variable still wasnt enough

You probably didn't restart VS to make it pick up the new value after you edited it.

I managed to download the source for hexchat and compile it. The problem still exists.

You're building HC using GTK+openssl built by us. To make changes to GTK you will need to build GTK.

[jackpoz]

Did any developer update to Windows 10 in the meantime ?

[jackpoz]

Tested HexChat 2.12.0 on Windows 10 x64, still same issue. I saw some Windows 8 features in the changelog, am I to believe finally someone upgraded to Windows 8+ and can now work on this issue ?

[jackpoz]

Looking at the data I gathered 596 days ago #830 (comment) it could be that MsgWaitForMultipleObjectsEx() is called with a timeout too small. https://blogs.msdn.microsoft.com/oldnewthing/20151113-00/?p=92111 also suggests another possible case where MsgWaitForMultipleObjectsEx() returns with an error that is handled by calling again the same function over and over and over.
As a 3rd possible cause and related fix there is https://bugzilla.gnome.org/show_bug.cgi?id=675695#c6 .

Would any hexchat developer feel like working together to fix this issue by checking the 3 possible causes mentioned above ( or will they just stare at the issue ) ?

Edit: continuing with blaming poor gpoll() implementation, https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg01425.html and https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg03572.html provide a patch to fix a "significant performance degradation of QEMU"

[Arnavion]

or will they just stare at the issue

Instead of waiting on us (which for gtk-win32 issues is basically just me), you can compile gtk-win32 yourself and test any patches you want.

[jackpoz]

HexChat build system is a nightmare, with custom Visual Studio build steps that don't support special characters or spaces and cryptic build errors. The repo layout HexChat chose scares away any developer who would attempt to build it (tried and gave up 3 times so far).

https://github.com/hexchat/gtk-win32/blob/master/README.md doesn't provide any way to get a .sln with HexChat and all the dependencies so one can just F5 and debug into the application and all related dependencies.

I profiled the issue, found a patch, opened a ticket to GTK+ https://bugzilla.gnome.org/show_bug.cgi?id=764415 and all you could write was "build it yourself". Going back to my question

Would any hexchat developer feel like working together to fix this issue ?

the answer is clearly "No"

[jtanx]

Hello, I noticed this bug while searching on the internet. I experienced the same issue and I think I've found the problem. See here: https://bugzilla.gnome.org/show_bug.cgi?id=771568

The patch is to GDK.

[jackpoz]

Thanks for the heads up @jtanx and for the patch.
@TingPing it seems the patch provided at https://bugzilla.gnome.org/show_bug.cgi?id=771568 for gtk+ fixes the issue, could it be merged ?

[TingPing]

@jackpoz Looks like they didn't backport that patch to Gtk2, I left a message so it will get into the next release.

[genbtc]

Please do

[jackpoz]

Any update on this ?

[TingPing]

These patches have been commited to gtk-2-24 upstream. So next time HexChat gets a release on a new enough gtk version it will be fixed.