Heavy TakeLock contention when serializing value types concurrently

[GoogleCodeExporter]

Please include an e-mail address if this might need a dialogue!
==============

What steps will reproduce the problem?

1. The following will reproduce the problem:

Func<object, byte[]> serialize = obj =>
{
    using (var ms = new MemoryStream())
    {
        Serializer.Serialize(ms, obj);
        return ms.ToArray();
    }
};

var tasks = new List<Task>();
for (var i = 0; i < 50000; i++)
{
    tasks.Add(Task.Factory.StartNew(() => serialize(Guid.NewGuid().ToString())));
}
Task.WaitAll(tasks.ToArray());

2. The following does not exhibit the problem:

[ProtoContract]
public class TestClass
{
    [ProtoMember(1)]
    public string Id { get; set; }
}

Func<object, byte[]> serialize = obj =>
{
    using (var ms = new MemoryStream())
    {
        Serializer.Serialize(ms, obj);
        return ms.ToArray();
    }
};

var tasks = new List<Task>();
for (var i = 0; i < 50000; i++)
{
    tasks.Add(Task.Factory.StartNew(() => serialize(new TestClass { Id = Guid.NewGuid().ToString() } )));
}
Task.WaitAll(tasks.ToArray());

What is the expected output? What do you see instead?

Profiling #1 above, TakeLock() is called ~50000 times. It is only called a 
handful of times in #2.

What version of the product are you using? On what operating system?

r622
Windows 7 / 2008 x64

Please provide any additional information below.

Similar to:
http://stackoverflow.com/questions/12396742/protobuf-net-concurrent-performance-
issue-in-takelock

Original issue reported on code.google.com by matt...@banek.net on 9 Apr 2013 at 3:02

[GoogleCodeExporter]

Interesting, thanks - although I should point out that when serializing naked 
values it hits a lot of sub-optimal routes; the best usage is to serialize an 
contract object that *has* a member of that type. I've tweaked the code 
locally; I need to regression-test etc.

Original comment by marc.gravell on 9 Apr 2013 at 12:03

• Changed state: Accepted

[GoogleCodeExporter]

Thanks for the quick response (and the library itself!)

This is happening in the context of a generic base class where T might be (and 
often is) a contract object, but might also be a built-in type.

Original comment by matt...@banek.net on 9 Apr 2013 at 1:59