mIRC Home    About    Download    Register    News    Help

Print Thread
CPU load spike at fixed interval, Nick Color issue #176929 16/05/07 11:06 PM
Joined: Dec 2002
Posts: 503
B
Bekar Offline OP
Fjord artisan
OP Offline
Fjord artisan
B
Joined: Dec 2002
Posts: 503
Hey,

Using mIRC 6.21 on a P4 3.2Ghz, on approx. 30 channels with approx. 4000 nicks total. Every 30 seconds or so there is a noticable CPU spike, which lasts between 5-8 seconds.

Turning off the 'Nick Colors' makes the spikes go away.

On my machine, I have 2 'Nick Colors' that are set for two user-levels (which only appear in one channel anyway), with the IAL enabled and up-to-date.

I know at least one other person who has the same issue.

Re: CPU load spike at fixed interval, Nick Color i [Re: Bekar] #176931 17/05/07 12:15 AM
Joined: Aug 2004
Posts: 7,252
R
RusselB Offline
Hoopy frood
Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
well, I can't say that I'm surprised that there's a noticeable spike in CPU resource use, given that your nick colors are trying to cover whatever settings you have them set for over 4000 nicks, and in addition to what ever other programs that you're using.
How much RAM do you have? How much free space on your hard drive?
The fact that the levels only appear in one channel, is, for the most part, irrelevant, as mIRC doesn't know this, so it monitors all of the channels that you're in for matches.

This, in my opinion, isn't a mIRC bug, but rather an extensive use of the options available in mIRC that require constant updating, and, therefore must be run from RAM, rather than being able to store the information in a file on the hard drive.

Technically, I suppose, the information could be stored on the hard drive, but I think you'd probably find a bigger lag than you currently do, as the hard drive would have to be accessed every time there's a comparison needed to be done.

Re: CPU load spike at fixed interval, Nick Color i [Re: RusselB] #176935 17/05/07 04:20 AM
Joined: Jul 2003
Posts: 655
Om3n Offline
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
I dont see why there should be a pause every 30 seconds or so in any case. The nick coloring should only be applied when neccersary (joining a chan, mode changes, sending text to the chan, etc), i dont see why there would be any need to 'refresh' it either?

I would assume that the number of nicks has little to no effect on how long it takes (aside from when you first join the channels), because each event that triggers it should be linked to just one nick/address. Of corse it would use more cpu in larger channels due to this being triggered much more often, but that in no way explains the pauses.

Im not convinced its a bug, but i certainly dont believe its the users fault for being in so many channels with so many people.

I would suggest turning remotes off (/remote off) and seing if it continues. My best guess given the information provided would be that the ial is doing large updates for some reason (/who +c on a timer for example?).


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Re: CPU load spike at fixed interval, Nick Color i [Re: Om3n] #176937 17/05/07 04:46 AM
Joined: Dec 2002
Posts: 503
B
Bekar Offline OP
Fjord artisan
OP Offline
Fjord artisan
B
Joined: Dec 2002
Posts: 503
Not remotes related, and I've got 3GB of memory, mIRC is only using 27-30MB.

Pauses when joining a channel are expected, as yes, I do staggered delayed /who's to update IAL's etc..

And I agree that the updates of nicklist coloration should be done upon event trigger, such as a join or mode etc..

In any case, to loop through and check each individual $ial() entry in mIRC Script takes considerably less than the pause that's being witnessed..

Re: CPU load spike at fixed interval, Nick Color i [Re: Bekar] #176939 17/05/07 04:56 AM
Joined: Aug 2004
Posts: 7,252
R
RusselB Offline
Hoopy frood
Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
I'm out of ideas, and I'm not on any networks that have the number of users that you're indicating in order to check it out myself, per your specifications. I did check it as close as I could with what I do have, and I while I did notice a delay when joining a channel, it was nowhere near what you're indicating, and it was only when I joined the channel.

Re: CPU load spike at fixed interval, Nick Color i [Re: Om3n] #176950 17/05/07 08:41 AM
Joined: Sep 2005
Posts: 2,876
H
hixxy Offline
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,876
Originally Posted By: Om3n
I dont see why there should be a pause every 30 seconds or so in any case. The nick coloring should only be applied when neccersary (joining a chan, mode changes, sending text to the chan, etc), i dont see why there would be any need to 'refresh' it either?


Updating nick colouring based on idle time maybe?

Re: CPU load spike at fixed interval, Nick Color i [Re: Bekar] #176961 17/05/07 11:33 AM
Joined: Oct 2004
Posts: 8,327
Riamus2 Offline
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,327
Type /timers and see what you have. Look at the time delay on them and see if you have any that are set to 30s or close to that. That will most likely be the cause.


Invision Support
#Invision on irc.irchighway.net
Re: CPU load spike at fixed interval, Nick Color i [Re: Riamus2] #176963 17/05/07 12:10 PM
Joined: Apr 2004
Posts: 840
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 840
Well, I am the "one other person" in Bekar's original post, and I can assure you that it's none of that. At least in my case, the CPU spike coincides with mIRC's notify check, which automatically happens every 30 seconds; I also get a spike when I type "/notify" (without parameters) forcing mIRC to update the notify list. And yes, this is with remote off..

The nicklist colouring entries I have all refer to userlevel entries; I suspect that updating the notify list somehow causes a loop to check all wildcard userlist entries against all nicknames on all channels I'm on, explaining the CPU spike. I've turned off nicklist colouring permanently as a result of this.


Saturn, QuakeNet staff
Re: CPU load spike at fixed interval, Nick Color i [Re: hixxy] #176965 17/05/07 12:45 PM
Joined: Jul 2003
Posts: 655
Om3n Offline
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
Originally Posted By: hixxy
Updating nick colouring based on idle time maybe?

It was my understanding that this is based only on what mirc see's and not on the ircd's idle time information, so im not sure even this case should or would cause any such issues? I would assume its just a lot of internal timers/trigger points of some kinda associated with nicks that get reset every time the user is seen active?


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Re: CPU load spike at fixed interval, Nick Color issue [Re: Bekar] #176974 17/05/07 05:34 PM
Joined: Dec 2002
Posts: 4,539
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,539
I can reproduce this here. I tested with 10 users in my user list (just nicknames) and was on channels with just over 4000 nicks total. It is due to the nick color list idle time check, which is triggered very 30 seconds.

mIRC looks through your nick color list entries and matches each of the 4000 nicks against each entry. This is necessary even if an entry does not have idle time checked, since a nick might match a prior non-idle time entry.

So two entries * 4000 nicks would be 8000 comparisons. Then, for each entry that has "user levels" checked, each nick must be individually compared to your entire user list for a best match. If your user list has 10 users in it, that would be 8000 x 10 = 80,000 calls to the routine that performs the (somewhat complex) nick/address/level parsing/matching.

I can't see a way of making it any faster. How big is your user list by the way?

Re: CPU load spike at fixed interval, Nick Color i [Re: Khaled] #176978 17/05/07 06:24 PM
Joined: Apr 2004
Posts: 840
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 840
Ah, so it was that after all! I wonder what /notify does in my case then.. shocked

Quote:
I can't see a way of making it any faster.

How about a true/false flag indicating whether there are any nick colour entries related to idle times at all? If not set, skip the 30-seconds check. Somewhat of a hack, but I'm willing to bet that most people don't use a combination of idletime-based and userlevel-based nick colouring...


Saturn, QuakeNet staff
Re: CPU load spike at fixed interval, Nick Color i [Re: Sat] #176994 18/05/07 12:33 AM
Joined: Dec 2002
Posts: 503
B
Bekar Offline OP
Fjord artisan
OP Offline
Fjord artisan
B
Joined: Dec 2002
Posts: 503
I have about 40 entries in my user-list.

The time taken makes more sense now given the loops involved.

Originally Posted By: Sat
How about a true/false flag indicating whether there are any nick colour entries related to idle times at all? If not set, skip the 30-seconds check. Somewhat of a hack, but I'm willing to bet that most people don't use a combination of idletime-based and userlevel-based nick colouring...


I'd agree with this. In my case, I only use user-level's for nick colors. So the extra tests within the loop aren't needed at all.

As for speeding it up, as user's addresses are available upon most events, would it be possible to 'cache' the matched entries, and thus only loop through the smaller subset.

Admittedly, this would make the JOIN/PART/QUIT/MODE/NICK events more difficult, but could possibly be tied to the IAL routines.

Notification of changes to the user-list could get nasty though..

I suppose the other approach would be to flatten/amalgamate the entire nick color list into a mask, so only one loop-iteration total would be required of the 4000, ignoring tests for the unselected/unused options. For those that match the big-mask in any manner, do finer grained tests and actions if required.

Re: CPU load spike at fixed interval, Nick Color i [Re: Bekar] #177004 18/05/07 06:21 AM
Joined: Jul 2003
Posts: 655
Om3n Offline
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
Guess i was wrong... but surely there has to be a better way to handle the idle time changes than looping through every nick with every entry in the options and user levels every 30 seconds.

hmm


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Re: CPU load spike at fixed interval, Nick Color i [Re: Om3n] #177005 18/05/07 08:56 AM
Joined: Dec 2002
Posts: 4,539
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,539
I've changed it so that it no longer updates all the nicks immediately. Instead, each nick is marked for update, and only those nicks that are visible in the listbox are updated. Nicks that are not visible are trickle updated in the background over time.

This results in a slower channels nick list display if nicks need to be updated but only in situations with thousands of users and a complex nick color list with large user lists/notify lists/etc. This is probably better than having mIRC freeze 5 to 8 seconds every thirty seconds :-)

This change should be in the next version.

Re: CPU load spike at fixed interval, Nick Color i [Re: Khaled] #177036 18/05/07 10:04 PM
Joined: Dec 2002
Posts: 503
B
Bekar Offline OP
Fjord artisan
OP Offline
Fjord artisan
B
Joined: Dec 2002
Posts: 503
Many thanks

Re: CPU load spike at fixed interval, Nick Color issue [Re: Khaled] #177095 19/05/07 08:13 PM
Joined: Apr 2003
Posts: 342
M
MeStinkBAD Offline
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
Quote:
I can reproduce this here. I tested with 10 users in my user list (just nicknames) and was on channels with just over 4000 nicks total. It is due to the nick color list idle time check, which is triggered very 30 seconds.

mIRC looks through your nick color list entries and matches each of the 4000 nicks against each entry. This is necessary even if an entry does not have idle time checked, since a nick might match a prior non-idle time entry.

So two entries * 4000 nicks would be 8000 comparisons. Then, for each entry that has "user levels" checked, each nick must be individually compared to your entire user list for a best match. If your user list has 10 users in it, that would be 8000 x 10 = 80,000 calls to the routine that performs the (somewhat complex) nick/address/level parsing/matching.

I can't see a way of making it any faster. How big is your user list by the way?


Is this code more effecient than your compiled code? I'm gonna run some tests and get back to you....


Beware of MeStinkBAD! He knows more than he actually does!