May 16, 2010 .NET, Concurrency, MasterDiploma, Performance
May 16, 2010 .NET, Concurrency, MasterDiploma, Performance
In recent time I was interacted with multithreading in .NET.
One of the intersting aspects of it is performance. Most of books says that we should not overplay with performance, because we could introduce ugly-super-not-catching bug. But since I’m using multithreading for my educational purposes I allow myself play with this.
Here is some list of performance tips that I’ve used:
1. UnsafeQueueUserWorkItem is faster than QueueUserWorkItem
Difference is in verification of Security Privileges. Unsafe version doesn’t care about privileges of calling code and runs everything in its own privileges scope.
2. Ensure that you don’t have redundant logic for scheduling your threads.
In my algorithm I have dozen of iterations on each of them I perform calculations on long list. So in order to make this paralleled I was dividing this list like [a|b|c|…]. My problem was in recalculating bounds on each iteration, but since list is always of the same size I could have calculating bounds once. So just ensure that don’t have such crap in your code.
3. Do not pass huge objects into your workers.
If you are using delegate ParameterizedThreadStart and pass lot of information with your param object it could decrease your performance. Slightly, but could. To avoid this you could put such information into some fields of the object that contains method for threading.
4. Ensure that you main thread is also busy guy!
I had this piece of code:
Do you see where I have performance gap? Answer is in utilizing my main thread. Currently it is only scheduling some number of threads (GridGroups) to do some work and than it waits for them to accomplish. If we divide work to approximately equivalent partitions, we could gave some work to our main thread, and in this way waiting time will be eliminated.
Following code gives us persormance increase:
5. ThreadPool and .NET Framework 4.0
Guys, from Microsoft improved performance of the ThreadPool significantly! I just changed target framework of my project to the .Net 4.0 and for worst cases in my app got 1.5x time improvement.
What’s next?
Looking forward that I also could create more sophisticated synchronization with Monitor.Pulse() and Monitor.WaitOne().
Good Threading Reference
Btw: I read this quick book Threading in C#. It is very good reference if you would like to remind threading in C# and to find some good tips on sync approaches.
P.S. If someone is interested if I woke up at 8am. (See my previous post). I need to say that I failed that attempt. I woke at 12pm.
Markdown | Result |
---|---|
*text* | text |
**text** | text |
***text*** | text |
`code` | code |
~~~ more code ~~~~ |
more code |
[Link](https://www.example.com) | Link |
* Listitem |
|
> Quote | Quote |
4. Ensure that you main thread is also busy guy!
does it really gives some performance gains? I thought that when you just wait in main thread for all other threads, than main thread is just suspended and is not using CPU at all… So where those performance improvements are taken from?
I was also thinking this way… but for some odd reason waiting for other threads also takes some time and plus to that I now need to allocate one thread less. So I think main reason is allocating less threads… (even if this done through ThreadPool)
ok, so I guess it's cost of allocating one more thread, but is it so heavy process, that you can see difference?
No, it is not so much heavy process. But in worst case when I have small grid and about 50000 iterations this start impacting performance.
You could see that that takes time, so improvements to 4.0 were really needed. Take a look:
http://blogs.msdn.com/pfxteam/archive/2010/04/13/9995622.aspx