C# Protobuf net在RuntimeTypeModel.TakeLock中花费的时间过多

我的问题与这个问题中的问题非常相似：。不同之处在于，在我们的例子中，我们使用压缩序列化和反序列化数据。每次我们需要反序列化数据时，都会从8核CPU上的8个不同线程调用以下代码

var result = new ProtoCompressedSerializer().Deserialize<Dictionary<string, CustomStruct>>(...)

以下是ANTS性能分析器的结果：

---

图中的第一个节点是我们的方法，它使用上面的代码调用反序列化。每个框中左边的数字是以秒为单位的时间，右边的数字是点击次数。正如您所看到的，RunTimeTypeModel.TakeLock占用了很多时间。在上面的链接问题中，建议对模型进行预编译。压缩序列化程序和它的反序列化方法是否可能？从性能角度来看，创建一个序列化程序并在所有线程之间共享它是否更好？它是线程安全的吗？

在尝试了几个选项并使用性能分析器比较了它们的性能之后，我得出结论，ProtoBuf net不正确地支持字典，甚至预先初始化序列化程序也无济于事

解决方案是将字典包装成一个新类，作为唯一的数据成员。这不仅将性能提高几倍，我们看到了3倍的改进，而且实际上还消除了TakeLock的使用和相关的超时问题

例如：

    [Serializable]
    [ProtoContract]
    [DataContract]
    public class ModelADict
    {
        [ProtoMember(1)]
        [DataMember]
        public Dictionary<string, ModelA> sub { get; set; }

        public ModelADict()
        {
            sub = new Dictionary<string, ModelA>();
        }
    }

---

在这种情况下，什么是ProtoCompressedSerializer？好吧，那不是protobuf网络文件；它在干什么？它封装了什么？对不起！刚刚意识到ProtoCompressedSerializer是一个内部类，由另一个团队实现，它首先解压缩传递给它的数据缓冲区，然后将未压缩的缓冲区作为内存流传递给ProtoBuf.Serializer.Deserialize。问题似乎仍在TakeLock中。我在检查元数据时发现超时异常。。。在我们的日志中。此外，我们正在反序列化大约200个数据类型，并发现了此相关错误以及@MarcGraveli的任何更新。我们已经快速了解了为什么它会如此猛烈地攻击此错误……但是您是否尝试过在启动期间调用PrepareSerializer，和/或增加超时？