[Mono-bugs] [Bug 418272] Scheduling time complexity of Sys.Threading.Timer is O(n)

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=418272

User lupus at novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=418272#c3





--- Comment #3 from Paolo Molaro <lupus at novell.com>  2008-09-08 13:14:36 MDT ---
It would be nice to have a completely scalable timer scheduler.
The standard solution is to have multiple queues for timers which expire within
1, 10, 100, etc seconds. Not sure that RBTree.cs would help much here for this
(besides it's using generics and is in System.dll).

That said, I don't think your description of the issue is fair: in that
scenario
you don't have timers expiring every 10 ms (try changing the timer in the test
to expire every 100 ms and the Sleep() call to sleep for 1 second and you'll
see
that it prints 1 all the time up  to tens of thousands of timers).
So the 'cpu' spikes need to be qualified: how much is that and how many timers
would a busy site have at once? Also note that even when the test doesn't print
1, the load on the cpu is fairly low.

So, in the end, it would be nice to behave better, but in real world cases I
don't think this issue matters much if at all.

I have a simple test change which uses just one additional queue for tasks that
expire after a few seconds and your contrieved test case seems to work fine.
I'll commit tomorrow after more testing.


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.