Is using ReaderWriterLockSlim a bad idea for long lived objects?

Posted by uriDium on Stack Overflow See other posts from Stack Overflow or by uriDium
Published on 2010-06-14T09:57:30Z Indexed on 2010/06/14 10:02 UTC
Read the original article Hit count: 451

I am trying to track down the reason that an application has periods of bad performance. I think that I have linked the bad performance to the points where Garbage Collection is run for Gen 2. I get a profiling tool (CLR Profiler) and was quite surprised by the results. In my test I was spawning and processing millions of objects. However the biggest hog of the Gen 2 space comes from something Called Threading.ReaderWriterCount which comes from System.Threading.ReaderWriterLockSlim::InitializeThreadCounts. I know nothing about the inner workings of ReaderWriterLockSlim but from what I am getting from the reports it is okay to have 1 or 2 Locks for longer lived objects but try and use other locks if you are going to have many smaller objects.

Does anyone have any comments or experience with ReaderWriterLockSlim and/or what to look for if it seems that GC is killing application performance?

© Stack Overflow or respective owner

Related posts about .NET

Related posts about Performance