http://bugzilla.novell.com/show_bug.cgi?id=624849
http://bugzilla.novell.com/show_bug.cgi?id=624849#c7 --- Comment #7 from Jérémie LAVAL <[email protected]> 2010-07-31 20:36:13 UTC --- (In reply to comment #6) > This reduces cpu usage to alot on this machine. However, when comparing > BlockingCollection (mono master) running on .net, with the built-in .net 4 > BlockingCollection, the mono version takes about 2% cpu, while the built-in > does not show up at all (less than 1%). This is all about tuning up number limit hence why I was asking. I will lower it a bit more. > I looked at the code and it seems there are no usage at all of any signaling > or > something. The .net version probably uses ManualResetEventSlim or > SemaphoreSlim > to actually sleep until it is signaled (by adding an element). The mono one > just spins alot which is plain wrong. (spinning should afaict only be used in > a > short while before actually waiting, but this behaviour is built-in to > ManualResetEventSlim and SemaphoreSlim) The *Slim things are designed to not use kernel objects or too much kernel level function so their stalling part is not as good as a real kernel object which is exactly their purpose i.e. having an object with the same behavior but for short lived wait not requiring any costly kernel operations. IMHO BlockingCollection has kinda the same spirit that is having maximal throughput between a producer (which when finished use AddingComplete) and a consumer which isn't the case in your scenario where I wouldn't use such collection. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
