Comments

# barrkel said on February 17, 2007 5:55 AM:

Can you explain what the axes of the graph represent?

I assume the Y-axis is number of calls to Monitor.Enter, but what are the fractional values on the X-axis?

# Mike Dunn said on February 17, 2007 8:35 AM:

X axis = log10(complexity)

Y axis = number of methods with that complexity

# jayson knight said on February 18, 2007 4:02 AM:

My guess would have to be System.Threading.Thread. It's probably not something that obvious though.

# Kent Boogaart said on February 18, 2007 9:38 PM:

Maybe one of the lock classes, like ReaderWriterLock? Dunno, but this sure is interesting stuff, Rico - thanks.

# Norman Diamond said on February 18, 2007 10:46 PM:

> Anyone care to guess what class has the

> methods with the greatest allocation

> complexity?

s/allocation/synchronization/?

If the numbers mean something other than the quantity of synchronizations, I guess they relate to an average length of time that methods are expected to wait while synchronizing.  Maybe that would be clients of networking stuff.

# ricom said on February 19, 2007 1:28 AM:

>> s/allocation/synchronization/?

Yes, sorry, I fixed that.

# Kent Boogaart said on February 19, 2007 2:15 AM:

I'm retracting my guess because I think RWLocks would implement their own locking mechanism rather than relying on Monitor.

I'll offer another vague cop-out of a guess: something in ASP.NET's caching infrastructure somewhere. Surely there'd have to be some pretty heavy locking there somewhere . . . ?

# Alois Kraus said on February 21, 2007 4:54 PM:

Hi Rico,

I guess you count the in the call graph Monitor.Enter where the winner function must be contained inside a deeply nested perhaps even recursive call graph. Recursive high level functions would qualify as good candiates for such a thing. A wild guess would be

System.Xml.Schema.XmlSchemaSet.RemoveRecursive(XmlSchema)

System.Configuration.BaseConfigurationRecord.CloseRecursive()

Calls to synchronized wrapper classes such as SyncArrayList could also produce such deep call graphs.

Yours,

  Alois Kraus

# Keith Patrick said on February 23, 2007 3:46 PM:

Since it's just guessing, and I don't have to browse through any classes, I'll throw out ThreadPool or WebRequest for most synch complexity, being that a thread or IO management would require a great deal of locking, and the file-based IO stuff can depend a lot on the FS to ensure locks

# David Conrad said on March 7, 2007 5:23 PM:

I second Norman Diamond's choice of Thread.

# Rico Mariani's Performance Tidbits said on March 22, 2007 4:00 PM:

Well it seems like an eternity ago but at last I'm writing the followup to my initial question about

New Comments to this post are disabled