Lately, well today, My Mirc has reallllly been acting up. When I looked at my task manager, mirc was sitting around 90%. Nor could I bring up Mirc (minimized in tray).
I haven't done any scripting today, so I doubt it's any of that.
P.S. This just started today, after like 2-3 years of Mirc usage.
This problem (high CPU usage by mIRC) has been brought up a few times over the past couple of years.
From what I can recall, the only 'solution' that has worked in most of the cases (exceptions being scenarios that have a lot of scripts running and using a lot of global variables, when local variables would've done the job nicely), is to simply reboot the computer and restart mIRC.
I realize that this probably isn't the solution you're wanting, but rather wondering why this is happening, but I'm sorry to say that there doesn't seem to be any rhyme or reason as to when it happens or why.
I've had this happen on a brand new clean installation, so that eliminates the scripts possibility, but a simple restart of my system and everything worked fine.
Can't be the solution. Just happened again today. Restarted, still goes on every random once in a while.
How random is "random" in consistency? Try unloading all scripts you may have loaded and see if it happens again. Also any updates recently installed, try reverting from them.
If you could reliably reproduce this high cpu peak and provide any further information, then we could work on solving the problem or troubleshooting further.
Like I said, I haven't scripted anything recently, but I am using an addon like NNS. So I'll try a fresh mIRC later.
Random, as in I have no clue when it might happen. Although I can say for certain, it never freezes while my active window is on it.
I've hit that bug fairly often since I moved to Vista x64.
I have observed it in a test session on my win2k8 server too.
From what I could see it seems to be linked with two type of conditions:
1.ping/pong events(regardless of if they should be displayed or not)
2.gdi redraw.(though that one might just be a consequence of #1)
(the issue seems to arise a lot more on vista than xp, which let's me think there's a part of gdi issues in it, since vista's gdi is about 3 times slower than xp's(for aero&architecture reasons, there's no more gdi hardware acceleration hooks in vista)
An "addon" like NoNameScript *is* a script (it's even in the script's name), and a fairly large one at that. Unload it as was suggested and test this issue again.
Using scripts and having problems with mIRC is far less "random" than problems with a clean copy of mIRC- especially since NNS has been the cause of many similar CPU usage issues in the past.
Also, the Vista comments are not exactly qualified. Ping/pong events happen once every ~120 seconds. It would be impossible for one event every 2 minutes to account for 90% utilization no matter how slow GDI was. Secondly, not displaying the ping/pong emits no GDI events, so if you claim it's the same either way, that rules out GDI (or Ping/Pong) to begin with. Frankly, the only way GDI could pull mIRC to 90% is if you're in 50+ high volume channels with 10+ messages per second or something..
On that note: how many channels / networks to you have open?
I'll ignore the nns&scripts part since it doesnt concern me.
ping/pong events can occur a lot more often than 120s if you have multiple server connections(in my case ~12, which means that if they were equisplit that'd be one every 10s)
Secondly I split the two elements because they might be unrelated but both guilty.
Finally one argument to it being something nasty is the fact that it only occurs after a while(I've seen it be fine for 12hours+), meaning it's either a form of fragmentation or memory saturation, or at least something similar.
How many channels/networks: 205/12.
Yes that's a lot, but no, mirc handles it extremely fine, especially in the first 12 or more hours. Most of these are low traffic, and barely get anywhere near filling the buffer(I rarely join big public channels) so the condition is not traffic related.
EDIT: when the freeze occurs it's not just a simple 1second freeze too, it's usually 5-10s, sometimes 20-30. That's a whole lot of computations since it stays in full cpu usage(saturating a core of my Q6600) during that time...
One every 12 seconds is also not even close to enough to cause any noticeable delay with GDI, again, no matter how slow GDI was.. In 12 seconds your computer has processed trillions of instructions-- the one GDI message wouldn't even amount to a quarter of a percent of your utilization. Ping/Pong events should immediately be ruled out as a possibility.
205 channels is a lot however. I could see that as being the cause. For every channel, mIRC maintains timers and other auxiliary information that is frequently updated in addition to many more GDI messages than the ping/pong event every 12 seconds. This is even more significant if you join all the channels at the same time (in an ON CONNECT event or using a bnc, for instance) because all internal housekeeping will be triggered at the same time. That could account for 5 seconds of delay every N seconds in a systematic fashion.
I should add that everytime I've heard of this freezing issue, the user was either on 100+ channels on multiple networks or had a bnc that maintained many channels for them. It is actually pretty well reported that mIRC doesn't handle many channels all that well. I really wouldn't be surprised if this is the case.
Can you reproduce the freezing on say, 5-10 channels across 1-3 networks?
1.Yes, the amount of processing needed is not even remotely enough to saturate a quad core for a dozen seconds without any specific activity going on.(The freezes re-occur for no reason suddenly, and often while typing text for some odd reason)
2.Yes it's a lot, but even with a lot of auxiliary info, it actually works perfectly for quite some time, and only becomes slow after a relatively long period of time. But yes, I am guessing it's the channels management that causes the issue because they're all joined exactly simultaneously.(bnc here indeed)
3.No.The issue needs many channels. I've never seen it on a small number of channels. And I do not recall seeing it on xp 32bit...