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.
