A change in the timer management code - possibly linked to point 147 in versions.txt - now causes starting of many timers to be extremely slow. For example:


The results on my machine:


At least for me this is an unacceptable amount slower..

confirmed here:
on mirc 6.16, it took 70 ms to start 100 timers
on mirc 6.17, it took 1061 ms to start 100 timers

this is a roughly 1500% increase of time .

What do u expect, hes having to do more code now to ensure they start in the order they are created, thus the longer create time.
You cant have your cake and eat it too.

Apart from the fact that I never requested to eat this cake in the first place, maybe you would have had somewhat of a point if the time to create a timer increased as more timers were active. However, as qwerty pointed out to me, this is not the case: every timer creation takes about 10-15ms, regardless of the number of timers active at that moment. No code that checks a single timer could reasonably take 15 ms.

Indeed it does take more than 15ms: due to the way Windows differentiates and orders timers and WM_TIMER messages, in order to ensure that the timers are triggered in the correct order, mIRC has to ensure there is enough of a millisecond delay inbetween each timer so that Windows will correctly trigger them in the order that they were started. There are no plans to change this I'm afraid.

It should be easy to let mIRC order them, instead of relying on Windows for this. I can help you with this if necessary, please let me know if you're interested. But in my opinion, having mIRC hang for 15ms every time a timer is started is really not an acceptable remedy for the relatively harmless issue of timer ordering. This cure is worse than the disease..

Actually I would guess that most scripts do not rely on ordering at all, so if you really don't want to fix this then I urge you to add a flag to /timer that orders the timer using this delay (or instead, negate this behaviour). Such timers should only have to be ordered in respect to other ordered timers anyway.

Does it really matter though since how many situations involve 100 timers being loaded at the same time?

I think a 1-2 sec lag is pretty easy to live with.

I fully agree. Any way of getting the old, fast behaviour back would be great. I'm sure many picture window scripters would agree too, as timers are a frequently used tool in such scripts (including a few of mine, which now run considerably slower).

Yes it does matter. It could also be 100 scripts each using one timer. And it will be noticeable with far less than that.


You're kidding, right? We're not talking about network lag, but about mIRC being unresponsive for 1-2 sec, with a 100% CPU spike. If you find that acceptable, then you don't have a very fast PC to begin with..

Although I understand that Khaled wanted to fix this timer order issue, I also think the fix is worse than the "bugged" version. The difference in performance in some scripts is very noticable, and imho not worth it with the current implementation of the fix.

I hope this will be undone, done differently, or with a flag for those who really care about the order.

The flag idea is a good one, this wasn't worth
the sacrifice of performance in my opinion.

Yeah, I'd agree, add a flag to use the old way, or get Sat to help you on this

I think it would be more logical to provide a switch to enable the new method. That way, existing scripts will default to the old method, and anyone needing the high-order-resolution timers can add the switch.

-genius_at_work

This is what I meant as well, revert back to
the old and add a switch for the new method.

Agreed, only just noticed this myself while testing some changes on my multiserver script, for testing puposes i had as little as 20 servers and it was very much noticable. (not due to slow pc by any means). Reverting back to the old method and providing a flag to enable the new method would be great if at all possible.

I agree too, I would like to see a flag to enable or disable new timer ordering method

I agree. I would like to see a flag for timer ordering method.

The speed in which timer's are being executed on 6.17 is indeed 'unacceptable'. The ‘timer loop method’ which has been used by many scripters over the last few years is now almost useless. Version 6.17 has left only one fast method to perform multiple, repeated instruction on mIRC. This is through the use of while loops, which as we know consume 100% cpu usage, are unstable, and often cause mIRC to freeze.

I agree with the flag proposition. Ordered timer's are not worth the current drop in performance.

uff the diference its too big. the problem doesn't only affect picwinners.. the timers loops its the only way to do recursive calls and non-frosen iteractions... a speed decrease like that made useless too muchs of my scripts...


PD:my apollogies for mi english

Khaled: "As for the timer, I'll be changing it in the next version so that the ordering
only works when a switch is specified, so it will return back to it's normal speed."

*sighs in relief*

"phew !" indeed ! now let's hope 6.18 won't take as much time to come as 6.17...

anyway ToKeN, don't you remember /timer 0 0 ? it's using one more alias, but still works quite good (even if StanZ recorded a loss in performance with this method since the former versions).