title: protobuf-net concurrent performance issue in TakeLock
body: <p>We're using protobuf-net for sending log messages between services.  When profiling stress testing, under high concurrency, we see very high CPU usage and that TakeLock in RuntimeTypeModel is the culprit.  The hot call stack looks something like:</p>
  
  <pre><code>*Our code...*
  ProtoBuf.Serializer.SerializeWithLengthPrefix(class System.IO.Stream,!!0,valuetype ProtoBuf.PrefixStyle)
  ProtoBuf.Serializer.SerializeWithLengthPrefix(class System.IO.Stream,!!0,valuetype ProtoBuf.PrefixStyle,int32)
  ProtoBuf.Meta.TypeModel.SerializeWithLengthPrefix(class System.IO.Stream,object,class System.Type,valuetype ProtoBuf.PrefixStyle,int32)
  ProtoBuf.Meta.TypeModel.SerializeWithLengthPrefix(class System.IO.Stream,object,class System.Type,valuetype ProtoBuf.PrefixStyle,int32,class ProtoBuf.SerializationContext)
  ProtoBuf.ProtoWriter.WriteObject(object,int32,class ProtoBuf.ProtoWriter,valuetype  ProtoBuf.PrefixStyle,int32)
  ProtoBuf.BclHelpers.WriteNetObject(object,class ProtoBuf.ProtoWriter,int32,valuetype 
  ProtoBuf.BclHelpers/NetObjectOptions)
  ProtoBuf.Meta.TypeModel.GetKey(class System.Type&amp;)
  ProtoBuf.Meta.RuntimeTypeModel.GetKey(class System.Type,bool,bool)
  ProtoBuf.Meta.RuntimeTypeModel.FindOrAddAuto(class System.Type,bool,bool,bool)
  ProtoBuf.Meta.RuntimeTypeModel.TakeLock(int32&amp;)
  [clr.dll]
  </code></pre>
  
  <p>I see that we can use the new precompiler to get a speed boost, but I'm wondering if that will get rid of the issue (sounds like it doesn't use reflection); it would be a bit of work for me to integrate this, so I haven't tested it yet.  I also see the option to call Serializer.PrepareSerializer.  My initial (small scale) testing didn't make the prepare seem promising.</p>
  
  <p>A little more info about the type we're serializing:</p>
  
  <pre><code>[ProtoContract]
  public class SomeMessage
  {
      [ProtoMember(1)]
      public SomeEnumType SomeEnum { get; set; }
  
      [ProtoMember(2)]
      public long SomeId{ get; set; }
  
      [ProtoMember(3)]
      public string SomeString{ get; set; }
  
      [ProtoMember(4)]
      public DateTime SomeDate { get; set; }
  
      [ProtoMember(5, DynamicType = true, OverwriteList = true)]
      public Collection&lt;object&gt; SomeArguments
  }
  </code></pre>
  
  <p>Thanks for your help!</p>
  
  <p>UPDATE 9/17</p>
  
  <p>Thanks for your response!  We're going to try the workaround you suggest and see if that fixes things.  </p>
  
  <p>This code lives in our logging system so, in the SomeMessage example, SomeString is really a format string (e.g. "Hello {0}") and the SomeArguments collection is a list of objects used to fill in the format string, just like String.Format.  Before we serialize, we look at each argument and call <code>DynamicSerializer.IsKnownType(argument.GetType())</code>, if it isn't known, we convert it to a string first.  I haven't looked at the ratios of data, but I'm pretty sure we have a lot of different strings coming in as arguments.  </p>
  
  <p>Let me know if this helps.  If you need, I'll try to get more details.</p>