mIRC Home    About    Download    Register    News    Help

Topic Options
#262140 - 06/01/18 02:59 AM mIRC Slowdowns for Massive Chan Activity
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2243
Loc: New Mexico Tech
This isn't anything new, but mIRC really takes a beating whenever there is a lot of channel buffer scrolling (printing) of events or even scripted echos. Printing text is really the slowest thing about mIRC over all other things. (Understandably so.)

I would like to suggest that mIRC keeps a buffer (if it doesn't already) of printing jobs it needs to perform, and if that buffer reaches a certain threshold of backlog, then mIRC can pause re-drawing (painting) updates until the buffer has been emptied.

This would fall under the same theory as using /draw* command's -n switch... to "prevents the display from being updated immediately."

Originally Posted By: mIRC Help
The -n switch prevents the display from being updated immediately. This allows you to make changes to the window in the background and then display the results only when you have finished. You can update the display by using any of the /draw commands with only the window name specified.


Whenever there's a netsplit, and you are in a sizable channel, or multiple sizable channels, mIRC suddenly spikes to 100% cpu and becomes mostly unresponsive until all the QUIT messages have been printed to the respective channels.

This will certainly have to use some self-awareness and introspection by mIRC to realize that a backlog of printing and painting is building up.
_________________________
doiní things a particle can

Top
#262235 - 11/01/18 12:22 PM Re: mIRC Slowdowns for Massive Chan Activity [Re: Raccoon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4035
Loc: London, UK
mIRC already does this. That is what the fast update feature was when it was available as an option in the display dialog. The option was removed and made permanent.

The issue is that when a large amount of information is being /echoed, mIRC has to update the display at some point. For example, if you run a script that /echos 10000 lines, at which point should mIRC display the text? The lines are being /echoed far faster than mIRC can update the display. Should mIRC just display the last page of text once the script finishes? The user would get no visual feedback that anything is happening until the script ends. Should it display a minimum of N lines per second? That number would depend on how powerful your CPU/GPU is.

Currently, mIRC updates the display reasonably often such that visual feedback is provided when displaying incoming lines, ie. the user can see the lines scrolling. That said, I think I can tweak it to update the display progressively less if a large number of lines are being /echoed in sequence.

Whether this would make any difference in the context you are describing, that is difficult to say.

Top
#262236 - 11/01/18 01:02 PM Re: mIRC Slowdowns for Massive Chan Activity [Re: Khaled]
Wims Offline
Planetary brain

Registered: 31/07/06
Posts: 3253
Loc: France
Most of the time I do like to get the visual feedback.
However I must say that sometimes when dealing with large number of data being echoed (Twitch context?), echoing all the lines as a debug makes mIRC take much more time than if the the window were hidden, and in this case I'd want to get mIRC to only display once the script finish. An option to enabled this in alt + o, with a command to toggle it, would be welcome. "/fastupd on" and "/fastupd off" once you are done debugging, that would be really nice for me.
_________________________
Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net

Top
#262242 - 12/01/18 02:43 PM Re: mIRC Slowdowns for Massive Chan Activity [Re: Khaled]
Jigsy Offline
Hoopy frood

Registered: 18/11/04
Posts: 781
Loc: I live inside your computer. S...
Originally Posted By: Khaled
Should it display a minimum of N lines per second? That number would depend on how powerful your CPU/GPU is.


Does mIRC actually do any kind of behind the scenes hardware acceleration?
_________________________
This signature is currently out of order. We apologize for the inconvenience.

Top
#262243 - 12/01/18 04:12 PM Re: mIRC Slowdowns for Massive Chan Activity [Re: Jigsy]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4035
Loc: London, UK
mIRC uses GDI which may nor may not be hardware accelerated depending on your version of Windows.

Top
#262261 - 14/01/18 09:22 AM Re: mIRC Slowdowns for Massive Chan Activity [Re: Raccoon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4035
Loc: London, UK
Quote:
Whenever there's a netsplit, and you are in a sizable channel, or multiple sizable channels, mIRC suddenly spikes to 100% cpu and becomes mostly unresponsive until all the QUIT messages have been printed to the respective channels.

I have just been experimenting with mIRC's display routine and the first thing I noticed is that it can currently /echo plain text at about 300 lines per second on my computer. That should be fast enough to handle quite a few QUIT messages. How many QUIT messages are we talking about here? How long is this delay? Are you sure the CPU usage isn't due to other features, such as scripts?

Top
#262262 - 14/01/18 09:41 AM Re: mIRC Slowdowns for Massive Chan Activity [Re: Wims]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4035
Loc: London, UK
Quote:
Most of the time I do like to get the visual feedback.

The next beta will include a change that makes mIRC progressively decrease the window update rate the more messages are /echoed in a small amount of time, ie. it kicks in during bursts of /echoes.

Visually, for the user, it transitions from a smooth scroll (every /echoed line is immediately displayed) to a jerky scroll (every 2/3/4/.../N lines up to a maximum are displayed). In most cases, the user should not be able to tell the difference because /echoed text is displayed in windows so quickly anyway. In my tests, the display speed has increased from 2-3 times on average to 10 times in some cases, depending on how many windows are being simultaneously updated, overlapped, hidden, and so on.

I have added a /fupdate N command that allows you to set the maximum reachable count before updates, so it can be enabled/disabled. It will always be disabled on startup.

This will be experimental for now but it may make sense as a permanently enabled feature in future.

Top
#262263 - 14/01/18 10:27 AM Re: mIRC Slowdowns for Massive Chan Activity [Re: Khaled]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2243
Loc: New Mexico Tech
Nifty! Thanks.

As far as your question about metrics goes:

On just one network, freenode being a larger network, right now I'm in channels with these populations. (Though I'm often popping in and out of different channels, some larger than others.)

[1960] [1267] [1243] [1039] [882] [851] [835] [795] [624] [588] [525] [506] [480] [475] [444] [425] [389] [371] [366] [348] [315] [309] [252] [251] [225] [225] [182] [173] [165] [155] [151] [148] [143] [143] [138] [121] [116] [113] [111] [109] [107] [107] [106] [102] [100] [89] [88] [87] [87] [86] [85] [82] [78] [76] [74] [68] [64] [60] [59] [50] [48] [48] [47] [47] [46] [46] [44] [40] [39] [39] [34] [31] [30] [25] [22] [22] [19] [18] [11] [7] == 20276

When there's a netsplit, I estimate at least 10 to 20% of those populations produce a quit message, which equates to about 2,000 to 4,000 quit messages being printed.

mIRC.exe usually idles around 2% ~ 6% for me, but peaks out at 50% (100% of a single core) for a fair period of time when there's a netsplit or re-join.

I know I can hide these event messages, but I do like to have access to them in my logs.
_________________________
doiní things a particle can

Top
#262264 - 14/01/18 11:40 AM Re: mIRC Slowdowns for Massive Chan Activity [Re: Khaled]
Wims Offline
Planetary brain

Registered: 31/07/06
Posts: 3253
Loc: France
Quote:
I have added a /fupdate N command that allows you to set the maximum reachable count before updates, so it can be enabled/disabled. It will always be disabled on startup.
Cool, thanks

I did see your original message saying the setting would be stored in mirc.ini and I agree that it's a good idea not to keep the setting stored, to always have it disabled at startup, one can always use an on start event if they want to permanently set it.
_________________________
Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net

Top
#262293 - 16/01/18 10:14 PM Re: mIRC Slowdowns for Massive Chan Activity [Re: Wims]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2243
Loc: New Mexico Tech
Khaled, I'm noticing about a 4x speed improvement in most test cases, so thanks! I would like to test this with values greater than 100, like 1000 or 10,000. Can you explain in some detail what this function does, and what the value means?

There is one scenario where no meaningful speed improvement is detected. That's when echoing a flood of text that contains various unicode symbols, especially through font linking (my hypothesis is that font linking is the bottleneck). Even just a few dozen symbols causes a 100 times slowdown on this accelerated graphics, 2.66 GHz Core2 Duo, 8 gig ram machine, compared to strings that contain ASCII only, according to my $calc($ticks - %ticks) benchmarks.
_________________________
doiní things a particle can

Top
#262294 - 17/01/18 08:07 AM Re: mIRC Slowdowns for Massive Chan Activity [Re: Raccoon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4035
Loc: London, UK
Quote:
I would like to test this with values greater than 100, like 1000 or 10,000. Can you explain in some detail what this function does, and what the value means?

This value simply sets the delay bewtween updates. 100 is the maximum value beyond which there is little improvement, so it will not be increased beyond that.

Quote:
There is one scenario where no meaningful speed improvement is detected. That's when echoing a flood of text that contains various unicode symbols

Yes, this indicates that the font linking is the bottleneck in this case. This cannot be improved. In future, mIRC may switch to a more modern and sophisticated method of displaying Unicode. This used to be Uniscribe but that has been replaced by DirectWrite. Unfortunately, both have their own issues. This would require a complete rewrite of the display routines. However, it is possible that using a newer method could make the display routine slower. There is no way to know without first implementing it, which would take a lot of work.

Top
#262296 - 17/01/18 09:11 AM Re: mIRC Slowdowns for Massive Chan Activity [Re: Khaled]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2243
Loc: New Mexico Tech
Ok. So a value of 100 means 100ms delay between paints, or a max refresh rate of 10 paints per second. Value of 50 is 20 fps. Got it.
_________________________
doiní things a particle can

Top
#262297 - 17/01/18 11:13 AM Re: mIRC Slowdowns for Massive Chan Activity [Re: Raccoon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4035
Loc: London, UK
Sometimes, 100 just means 100 :-) It's not milliseconds but... it is a value of arbitrary fuzziness that has a great bearing on the outcome.

Top