mIRC Home    About    Download    Register    News    Help

Print Thread
window -b is now 3-4x slower #156029 11/08/06 01:52 AM
Joined: Jan 2004
Posts: 1,202
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,202
//var %rows 2000 | var %b 100 | window -c @test | window -hl @test | var %i %rows | while (%i) { aline @test $str(abc $rand(1000,9999),50) | dec %i } | var %i %b | var %t $ticks | while (%i) { window -b @test | dec %i } | echo -s 8,4version $version takes $calc($ticks - %t) ticks to perform %b "window -b"'s in window of %rows rows

In mIRC 6.16 and 6.2 both running at the same time on the same PC:

8,4version 6.16 takes 2141 ticks to perform 100 "window -b"'s in window of 2000 rows

8,4version 6.2 takes 8406 ticks to perform 100 "window -b"'s in window of 2000 rows

This might be related to some of the other backwards scrolling and invisible text problems. It doesn't seem to matter whether or not the window and added line are tabbed or not. The time seems to be proportionally related to the number of rows and the number of times doing the /window -b, as well as changing the line length by changing the 50 - but any of these 3 parameters being changed still leaves both mIRC's with the same 3-4x ratio of time to perform the window -b's.

I found this problem while investigating the source of intermittent keyboard stalls after upgrading to mIRC 6.2. It seems there's a longer time to perform $fline searches also, but it's hard to track that down, since the searches fluctuate so wildly in time length.

Re: window -b is now 3-4x slower #156030 11/08/06 02:23 AM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Its the added processing time needed to get the length of each line, when having to check for line lengths effected by UTF support.


version 6.2 takes 7203 ticks to perform 100 "window -b"'s in window of 2000 rows

and then Alt-o/irc/messages/utf-8 display (untick)

version 6.2 takes 843 ticks to perform 100 "window -b"'s in window of 2000 rows

Re: window -b is now 3-4x slower #156031 11/08/06 02:33 AM
Joined: Jan 2004
Posts: 1,202
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,202
that's good to know about the utf-8 settings killing performance. I'll be sure to warn folks that don't need it to make sure it's turned off. But alas, that doesn't solve this issue. The 6.2's UTF-8 setting was never turned on, so I turned it on to see what happens, yikes!:

8,4version 6.2 takes 93500 ticks to perform 100 "window -b"'s in window of 2000 rows

Re: window -b is now 3-4x slower #156032 11/08/06 06:38 PM
Joined: Dec 2002
Posts: 4,563
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,563
Thanks, this is in fact due to the UTF-8 routines. I've optimized the routines and /window -b now performs significantly better, though not as fast as in previous versions.

Re: window -b is now 3-4x slower #156033 12/08/06 12:36 AM
Joined: Jan 2004
Posts: 1,202
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,202
Quote:
Thanks, this is in fact due to the UTF-8 routines. I've optimized the routines and /window -b now performs significantly better, though not as fast as in previous versions.


Are you referring only to the 12-times-as-slow when UTF-8 is enabled vs not-enabled, or also the 3-4 times as slow between 6.16 and 6.2 even when UTF-8 isn't enabled?

thanks

Re: window -b is now 3-4x slower #156034 12/08/06 07:12 AM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Quote:
8,4version 6.2 takes 93500 ticks to perform 100 "window -b"'s in window of 2000 rows


There is a fix for that, its called get a less crappy pc <snicker snicker>

Re: window -b is now 3-4x slower #156035 12/08/06 04:13 PM
Joined: Jan 2004
Posts: 1,202
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,202
You're having the same 10x as slow issues with the UTF-8 setting that I have. I had someone else test 6.2, and they had the same slowness factor, and had similar speeds pairs that I had.

I found someone using 6.17, and the UTF-8 setting had no effect on the ticks they used.

Doesn't seem to me that the UTF-8 routines should slow things down compared to 6.16, if UTF-8 isn't even checked.