mIRC Home    About    Download    Register    News    Help

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

Registered: 18/02/03
Posts: 2435
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: 4198
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: 3394
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: 797
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: 4198
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: 4198
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: 4198
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: 2435
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: 3394
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: 2435
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: 4198
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 optimized further at this stage. 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: 2435
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: 4198
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
#262434 - 30/01/18 05:17 PM Re: mIRC Slowdowns for Massive Chan Activity [Re: Raccoon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4198
Loc: London, UK
For those of you who have tried out /fupdate, what do you think about mIRC having this option enabled by default? Would it make any significant difference to users visually?

Top
#262437 - 30/01/18 07:53 PM Re: mIRC Slowdowns for Massive Chan Activity [Re: Khaled]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2435
It has been handy and I have noticed some improvement already in really aggressive channel activity or quit/join events.

But you are correct, too, in that it isn't necessarily very pretty, at least when it's set to 100. I haven't tested any other values yet, and I'm not sure what behaviors I should expect to change. At 100 it is very jittery for even small 4 or 5 line message bursts, and not just 10 or 20 or 50 or 2000 line bursts.

I would say the parameter should be something more intuitive that the user can understand exactly what's happening, maybe the ability to set a smoothness delay of 1 or 2 seconds before giving up on smoothness and catching up on the backlog of paints.

If I set the value to 25 or 50, should it stay smoother for longer, but still be as aggressive in out clearing the backlog quickly?
_________________________
doin’ things a particle can

Top
#262438 - 30/01/18 08:32 PM Re: mIRC Slowdowns for Massive Chan Activity [Re: Raccoon]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2435
Here is a test of 11x 1000 iteration loops, timing /fupdate from 0 to 10 to 20 ... to 100. And my results.

//window -ae @test | var %j = 0, %s | while (%j <= 100) { fupdate %j | var %i = 1, %n = 1000, %t = $ticks | while (%i < %n) { echo $calc(%i % 100) @test %i $str(X,100) | inc %i } | var %m = $calc($ticks - %t), %s = %s $+(%j,:,%m) | echo 4 -a done. fupdate= %j in %m ms. | inc %j 10 } | echo 13 -a DONE. (fupdate:millisec) %s

DONE. (fupdate:millisec) 0:14196 10:1841 20:1248 30:1061 40:920 50:842 60:749 70:702 80:609 90:546 100:499
DONE. (fupdate:millisec) 0:14165 10:1841 20:1232 30:1030 40:873 50:874 60:764 70:656 80:608 90:577 100:499
DONE. (fupdate:millisec) 0:14228 10:1778 20:1217 30:1076 40:905 50:842 60:780 70:702 80:609 90:577 100:499

I also notice that if I increase $str(X,100) to $str(X,200), it adds about 125 ms to each value. (this seems like quite a lot!)

DONE. (fupdate:millisec) 0:14399 10:1966 20:1435 30:1201 40:1108 50:1014 60:889 70:842 80:749 90:655 100:624

Also, /fupdate 1 == 4742 ms, or 3 times faster than /fupdate 0.

Honestly, it's a very cool feature (!!!) but I think choosing a value is pretty academic. It should perhaps automatically slide from 0 to 100 as time progresses, with some more gradient between 0 and 1, and some extra speed improvement beyond 100 if possible. eg, 0 .25 .50 1.0 5 10 25 50 100 250 500 1000. Or something, ramping up with each passing second that mIRC has more than 50 or 100 lines queued to be painted without break.

I wouldn't mind if /fupdate had a short delay before it kicks in. 2 or 3 or 5 seconds, or if less than 20 or 50 lines are waiting, otherwise /fupdate 100 kicks in.
_________________________
doin’ things a particle can

Top
#262439 - 30/01/18 08:56 PM Re: mIRC Slowdowns for Massive Chan Activity [Re: Raccoon]
maroon Offline
Hoopy frood

Registered: 12/01/04
Posts: 869
I tweaked Raccoon's script to have interval 1 instead of 10, and my curve is faster and similar but not the same as his. I have a GTX 750 video card, so that would explain why my times are quicker.

DONE. (fupdate:millisec) 0:1154 1:562 2:499 3:468 4:452 5:437 6:406 7:405 8:390 9:374 10:390 11:375 12:390 13:358 14:359 15:359 16:358 17:359 18:359 19:359 20:343 21:343 22:343 23:344 24:343 25:343 26:343 27:312 28:312 29:312 30:312 31:297 32:296 33:281 34:281 35:280 36:281 37:265 38:266 39:265 40:250 41:249 42:250 43:234 44:249 45:234 46:234 47:234 48:234 49:219 50:234 51:218 52:234 53:203 54:218 55:219 56:218 57:203 58:203 59:203 60:202 61:203 62:203 63:203 64:187 65:187 66:203 67:187 68:187 69:187 70:203 71:203 72:171 73:188 74:187 75:187 76:172 77:187 78:171 79:188 80:171 81:172 82:171 83:172 84:172 85:171 86:187 87:156 88:172 89:172 90:171 91:172 92:156 93:171 94:156 95:172 96:156 97:172 98:156 99:156 100:171

I'm seeing more time improvement from 0->1 than I'm seeing from 1->100, with 71-100 basically being the same number.

The sharp change from 0 to 1 can be noticeable in some cases, such as how this changes from a smooth scroll as you change fupdate values during:

Quote:
/play -es versions.txt 1


Edit: Previous test was with Consolas 14pt in a normal window. Rerunning the numbers in a maximized window using 9pt Fixedsys Excelsior NoLiga:

DONE. (fupdate:millisec) 0:1856 1:671 2:546 3:437 4:390 5:405 6:359 7:343 8:328 9:312 10:296 11:297 12:296 13:265 14:265 15:250 16:265 17:249 18:250 19:265 20:234 21:234 22:234 23:234 24:219 25:234 26:218 27:218 28:234 29:219 30:203 31:218 32:218 33:219 34:203 35:202 36:234 37:203 38:203 39:203 40:203 41:202 42:188 43:187 44:203 45:203 46:203 47:187 48:187 49:203 50:187 51:187 52:187 53:203 54:187 55:188 56:202 57:188 58:171 59:187 60:188 61:171 62:187 63:172 64:172 65:187 66:156 67:172 68:172 69:156 70:171 71:172 72:156 73:171 74:156 75:172 76:156 77:156 78:156 79:156 80:156 81:156 82:156 83:156 84:156 85:140 86:156 87:156 88:156 89:140 90:141 91:156 92:156 93:140 94:156 95:141 96:140 97:140 98:141 99:156 100:140

And now I'm seeing the 3x gain from 0->1. Now changing $str to use 100 $chr(10004)'s instead of X's:

DONE. (fupdate:millisec) 0:2184 1:936 2:827 3:780 4:546 5:515 6:483 7:640 8:608 9:609 10:577 11:593 12:561 13:578 14:546 15:561 16:531 17:546 18:546 19:530 20:515 21:530 22:515 23:515 24:515 25:514 26:500 27:499 28:515 29:499 30:500 31:499 32:499 33:499 34:484 35:499 36:483 37:484 38:483 39:484 40:484 41:499 42:468 43:483 44:468 45:484 46:484 47:468 48:483 49:468 50:484 51:452 52:484 53:468 54:468 55:468 56:437 57:468 58:436 59:453 60:452 61:437 62:437 63:452 64:422 65:436 66:406 67:437 68:405 69:422 70:390 71:421 72:390 73:421 74:390 75:390 76:390 77:421 78:375 79:405 80:375 81:390 82:374 83:390 84:374 85:390 86:359 87:375 88:358 89:375 90:359 91:374 92:343 93:375 94:343 95:359 96:343 97:343 98:343 99:359 100:343

Now changing $str to go back to using X, 200 instead of 100 X's in a wide maximized window that's not letting the line wrap:

DONE. (fupdate:millisec) 0:1950 1:733 2:593 3:531 4:514 5:468 6:437 7:406 8:405 9:390 10:359 11:359 12:359 13:327 14:344 15:343 16:312 17:312 18:328 19:296 20:312 21:312 22:297 23:296 24:297 25:281 26:296 27:297 28:281 29:280 30:281 31:281 32:281 33:281 34:280 35:266 36:265 37:281 38:265 39:281 40:265 41:281 42:265 43:266 44:265 45:265 46:265 47:265 48:266 49:265 50:249 51:250 52:265 53:265 54:265 55:265 56:250 57:250 58:265 59:234 60:249 61:266 62:234 63:249 64:234 65:234 66:234 67:234 68:234 69:219 70:218 71:218 72:218 73:219 74:234 75:203 76:218 77:218 78:219 79:218 80:203 81:218 82:203 83:219 84:202 85:203 86:203 87:218 88:203 89:203 90:187 91:203 92:203 93:187 94:203 95:203 96:187 97:187 98:187 99:203 100:187


Edited by maroon (30/01/18 09:25 PM)

Top
#262440 - 30/01/18 09:28 PM Re: mIRC Slowdowns for Massive Chan Activity [Re: maroon]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2435
Thanks maroon.

Yeah, what do you think. Should there be an automatic ramping of /fupdate from 0 to 1 to 100, after a preset delay, or how would this work as a user friendly feature?
_________________________
doin’ things a particle can

Top
#262443 - 31/01/18 11:26 AM Re: mIRC Slowdowns for Massive Chan Activity [Re: Raccoon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4198
Loc: London, UK
The ramping up/ramping down is part of how /fupdate works, ie. to react quickly to bursts of messages. I cannot add another level to that.

As you mentioned, with timer/play-based echoes, scrolling text appears more jerky because there is a continuous stream. For incoming messages, this is not as much of an issue, as messages often arrive intermittently.

That said, I could disable /fupdate for timer/play-based echoes/commands, so that they update windows immediately. This would allow us to set a /fupdate default which would only kick in during non-timer-based echoes, ie. message burts.

Top
#262444 - 31/01/18 11:49 AM Re: mIRC Slowdowns for Massive Chan Activity [Re: Khaled]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2435
On my end, 4 line pastes are painted in 2 distinct parts, with /fupdate enabled. That is, a clipboard paste into my multi-line editbox and hitting enter to send all 4 lines to the channel immediately. With /fupdate at 1 or 100, it's on without apology.

Code:
   (ö)_/¯  __(ö) \  \__(ö)__/  __(ö)__  ¯\_(ö)     / (ö)__  ¯\_(ö)_/¯  __(ö)__ 
_/¯|¡|     \ |¡|¯¯     |¡|     \ |¡| /     |¡|¯\_  ¯¯|¡| /     |¡|     \ |¡| / 
   \~\       /~\/¯     /~\     ¯\/~\       /~/     ¯\/~\       /~\       /~/   
  _/ /_     _\       _/   \_        \_    _\ \_        /_     /_ _\    _/ _\   
_________________________
doin’ things a particle can

Top
Page 1 of 2 1 2 >