Forums Bug Reports window -b is now 3-4x slower

//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.

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

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

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

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

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.