mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Dec 2019
Posts: 8
T
T20 Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Dec 2019
Posts: 8
I have been running mIRC on the same computer for ~8 years now. As far back as I can remember it has been using a surprising share of the CPU time. I'm on many networks and quite some channels though. This is a server that has some other things to do, and recently it has been assigned some more real-time critical jobs that suffers because of mIRC constantly using 20-50 % of the CPU (average % over a longer time is 25-30).

The CPU is an AMD Turion II Neo @ 1.5 GHz (dual core). 4 GB of RAM (but seldom using allocating more than 50-75 % of it). System/mIRC disk is a fast SSD on SATA-II in AHCI mode (disk access is very low). Operating system is Windows 2019 Server (Datacenter edition, 64-bit), things were the same with Server 2012 R2 and 2008 R2. Using the integrated GPU or an Nvidia Geforce GT710 makes no difference.

Memory, disk access and network traffic are never close to being bottlenecks and mIRC uses very little of them, it is just the CPU time that is the problem. The mIRC GUI is also rather unresponsive and switching channel windows , typing in the input field or scrolling in backlog has noticeable lag, from fractions of a second to several seconds until a response is seen (not response to running a command, just showing what I type). This happens even when the CPU is not running at full load, other programs run fine.

I am looking for help in what I can do to make mIRC use less CPU, and hopefully also make it more responsive, without crippling it by lowering the process priority.

I am on ~55 channels over 22 networks, none of the channels have any real heavy traffic.

What I have done already is that I have removed all scripts, all DLLs, all aliases, all user variables, cut down on logging, looked through all settings to find settings which I could suspect slow things down (mostly Windows GUI interactions like desktop windows, "tips" and animations, but I might have missed settings that I don't understand fully!?) and tried a clean install in portable format. Nothing has made a noticeable difference. I have read about others who had problems with mIRC using all CPU specifically when they were using scroll bars or similar, but I have not been able to replicate such a problem here. I have experimented with the /fupdate setting (0 or 100) without any improvement.

If I run mIRC without any server connection and without opening up the server/channel windows, it uses 0 %, even if the application is focused. I can push it up a few percent if I interact with it.

If I have all my usual server/channel windows open but disconnected and with mIRC still open and in focus, mIRC uses 18-22 % CPU most of the time, but jumps up to 45-50 % 3-4 times/minute, over time average is ~25 %..It is still clearly unresponsive and jumps up to 45-50 % much more often when I type in the input field. Keeping mIRC minimized in this state lowers the CPU use by 1-2 % only, with the increases to 45-50 % occurring 2-3 times/minute, average use ~22 %.

So, what can I do? Is it possible to use mIRC with my number of networks and channels without the heavy CPU use? Is there some way I can troubleshoot things and see what it is spending all this processing power on? Do you have some general good advice for settings or other things that might help me?

Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
I don't know your solution, just some things to try:

1. See if speeding up screen writes makes the problem go away: /fupdate 99
Note that /fupdate doesn't appear to have a mirc.ini setting, so you must do it each time you restart

2. See if exempting the mirc folder from your antivirus can prevent it from slowing down the client's disk accesses.
See https://forums.mirc.com/ubbthreads.php/topics/260678/windows-8-1-write-very-very-very-slowly

3. You weren't clear whether you were using. If it's older than 7.52, there was a bug fix that helped against a freeze.
11.Fixed online timer bug that caused mIRC to freeze once a minute the more connected status windows were open.

4. Test whether it happens with a partial setup. If it happens with 22/50, does the problem go away when you kill some of the status windows, or does ithe problem not appear until you've added the Nth status window? etc.

Joined: Dec 2019
Posts: 8
T
T20 Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Dec 2019
Posts: 8
Thanks for your response, forum hero!

1. Already tried /fupdate, no noticeable effect.

2. No antivirus running, same situation.

3. Using mIRC v 7.63 now. The situation has been the same for many years though, and I keep mIRC updated

4. Good idea, thanks! I will try that and report the results.

I also tried switching fonts around, after reading something about problems related to that. Didn't seem to help though.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
You could also try turning off the switchbar and treebar to see if that makes a difference. The switchbar/treebar are probably the most resource intensive features because they are graphics-based and need to be updated repeatedly in different contexts, eg. name coloring based on events, blinking, custom window ordering, etc.

Most graphics-related features, including display text in windows, have been updated over the years to use bitmap caching which, depending on your CPU/GPU, could also be resource intensive.

Other features that can be resource intensive are the "Nick Colors" feature, eg. if you are on many channels, with many users, and you have asked the Nick List feature to color nicks based on idle time, that could mean that tens of thousands of nicks need to have their individual idle times monitored/updated.

While most features have been optimized to use hash tables, in some cases it is not possible to use these, eg. where wildcard/regex matches are used, and so on. A feature like the IAL, which stores/updates details on potentially tens of thousands of nicknames if you have many channels open, could possibly cause a slow down.

As maroon mentioned, you would probably need to experiment with disabling features and joining a smaller number of channels, with fewer users, to see where the slow down starts. That might help narrow it down.

Joined: Dec 2019
Posts: 8
T
T20 Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Dec 2019
Posts: 8
Thanks for your attention and help!

I have done a lot of things the last days trying to pin down this, experimenting within mIRC, making changes in Windows and I've also been doing some unrelated hardware changes to the server. It turned out that this last thing was what would lead me to the solution.

I will not bother you with a story of all my experimentation, but jump straight to the point. The real cause of the problem is strongly tied to Microsoft's Remote Desktop implementation.

What I perhaps omitted to tell you, because I didn't understand the significance of it at the time, is that this is a server that I usually only Remote Desktop into, and that it very seldom has a display attached.

When I did the hardware work on it I had a physical display attached and logged in locally and did some required reboots. I very soon noticed that mIRC suprisingly used only (the expected) 3-5 % of CPU time, despite no other relevant changes to the system.

I then connected to the server with Remote Desktop (from a Windows 10 workstation), and immediately the problem was as described earlier. What is even more interesting, is that if I logged out of the remote session, mIRC did not go back to it's earlier relaxed state but it kept using up 20-50 % CPU until rebooting the server. A heavier load while accessing the server remotely would have been acceptable to me, but this was obviously not the case here.

I also noticed that some other applications were clearly also affected in the same way, but certainly not all. The common thing between them seemed to be that they were quite "GUI-heavy". The extra CPU load also seemed to correspond well with how GUI-heavy they were, mIRC being the extreme example. This seemed to fit well with my earlier observations that the exaggerated CPU load of mIRC scaled well corresponding to the number of channel/network windows I had open.

I read up on RDP and tried every possible recommended setting related to hardware acceleration and other things, but it did not help. I also found that I was not alone in finding similar issues (but the really big problem for most with RDP was with OpenGL applications, there is even a new Remote Desktop Accelerator by Nvidia for their graphics cards which I tried installing but it didn't seem to do much good in my non-OpenGL case). In some cases there were reports that installing a "HDMI dummy"/"EDID emulator"/"ghost display plug" helped with similar RDP issues, but I have not had the opportunity to try this yet.

I know Microsoft's Remote Desktop system works quite differently from other similar solutions, like TeamViewer or VNC. So I tried using RealVNC (I think any of them would have been just as useful) and wow, I could have remote desktop access to my server without any of the described problems, mIRC was now nicely using around 3-5 % CPU, as expected. The VNC server application and associated services surely use a lot of CPU while I am connected, but as soon as I minimize the window, the CPU load is negligible.

So, a happy end to the issue! I still hope though that this is something that will be fixed in RDP, in graphics drivers, or at the OS level, because if it were not for the issue described here I much prefer RDP over the alternatives.

I am thankful for your help, sorry to perhaps have wasted your time, and hope this story can be helpful to someone else with a similar problem.
It might also be useful to know that you should be able to run mIRC with 55 channels over 22 networks, some scripts, logging and various bells and whistles options using a hardly noticeable share of CPU power even on a lowly Turion II @ 1.5 GHz.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for the update. Glad you were able to track down the cause and find a solution :-)


Link Copied to Clipboard