22

在具有大量字段的类上调用简单的 XmlSerializer.Deserizlize() 时,我遇到了非常巨大的性能损失。

注意:我在家里编写没有 Visual Studio 的代码,所以它可能有一些错误。

我的可序列化类是扁平的,有数百个字段:

[Serializable]
class Foo
{
    public Foo() { }

    [XmlElement(ElementName = "Field1")]
    public string Field1;

    // [...] 500 Fields defined in the same way

    [XmlElement(ElementName = "Field500")]
    public string Field500;
}

我的应用程序反序列化输入字符串(甚至很小):

 StringReader sr = new StringReader(@"<Foo><Field1>foo</Field1></Foo>");
 XmlSerializer serializer = new XmlSerializer(typeof(Foo));
 object o = serializer.Deserialize(sr);

在 32 位系统中运行应用程序(或使用 corflags.exe 强制 32 位),代码第一次大约需要ONE SECOND(临时序列化类生成,以及所有......),然后它接近 0。

在 64 位系统中运行应用程序,代码第一次需要ONE MINUTE,然后接近 0。

在 64 位系统中,对于一个大类,在第一次执行 XmlSerializer 期间,什么可能会使系统挂起这么长时间?

现在我不确定我是否必须责怪临时类生成/删除、xml 名称表初始化、CAS、Windows 搜索、防病毒或圣诞老人......

剧透

这是我的测试,如果您不想被我的(可能的)分析错误所吸引,请不要阅读此内容。

  • 从 Visual Studio 调试器运行代码使代码即使在 64 位系统中也能快速运行
  • 添加(完全未记录的)system.diagnostic 开关“XmlSerialization.Compile”,防止系统删除序列化临时类,使代码即使在 64 位系统中也能快速运行
  • 采用运行时创建的临时 FooXmlSerializer 类,包括我项目中的 .cs,并使用它而不是 XmlSerializer,即使在 64 位系统中也可以使代码快速运行
  • 使用 sgen.exe 创建相同的 FooXmlSerializer 类,包括我项目中的 .cs,并使用它代替 XmlSerializer,即使在 64 位系统中也可以快速运行代码
  • 使用 sgen.exe 创建相同的 FooXmlSerializer 类,在我的项目中引用 Foo.XmlSerializers.dll 程序集,并使用它而不是 XmlSerializer,即使在 64 位系统中也使代码运行缓慢(这让我很烦恼)
  • 仅当反序列化的输入实际上包含大类的字段时才会发生性能损失(这也让我很烦恼

为了进一步解释最后一点,如果我有课:

[Serializable]
class Bar
{
    public Bar() { }

    [XmlElement(ElementName = "Foo")]
    public Foo Foo; // my class with 500 fields
}

仅在传递 Foo 孩子时反序列化很慢。即使我已经执行了反序列化:

 StringReader sr = new StringReader(@"<Bar></Bar>");
 XmlSerializer serializer = new XmlSerializer(typeof(Bar));
 object o = serializer.Deserialize(sr); // FAST

 StringReader sr = new StringReader(@"<Bar><Foo><Field1>foo</Field1></Foo></Bar>");
 XmlSerializer serializer = new XmlSerializer(typeof(Bar));
 object o = serializer.Deserialize(sr); // SLOW

编辑我忘了说我用进程监视器分析了执行,我没有看到任何任务从我的应用程序或 csc.exe 或任何与框架相关的东西中花费很长时间。系统只是做其他事情(或者我遗漏了一些东西),比如防病毒、explorer.exe、Windows 搜索索引(已经尝试关闭它们)

4

4 回答 4

9

我根本不知道这是否相关,但我遇到了 XSLT 的问题,并发现了微软关于 64 位 JITter 的那些相当有趣的评论:

问题的根源与两件事有关:首先,x64 JIT 编译器有一些二次缩放算法。不幸的是,其中之一是调试信息生成器。所以对于非常大的方法,它真的会失控。

[...]

64 位 JIT 中的一些算法具有多项式缩放。我们实际上正在努力将 32 位 JIT 编译器移植到 x64,但这要等到运行时的下一个并行版本(如“2.0 和 4.0 并行运行”中)才会出现,但 3.0/3.5/3.5SP1 是“就地”版本)。我已将其切换为“建议”,因此我可以将其连接到 JIT 吞吐量工作项,以确保在新移植的 JIT 已准备好发货。

同样,这是一个完全不同的问题,但在我看来,64 位 JITter 注释是通用的。

于 2010-11-10T02:00:34.193 回答
6

更新

我能够重现这一点,调查表明大部分时间都花在了 JIT 编译器上:

JittingStarted:“Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderFoo”、“Read2_Foo”、“实例类 SerializersTester.Foo”

无需任何分析器工具即可轻松证明这一点。

  • 通过 sgen 为 x86 和 x64 目标生成 *.XmlSerializers.dll
  • 通过 ngen 生成本机图像。

您会注意到与 x86 汇编相比,x64 生成会慢得多

确切的原因隐藏在 x64 JIT 内部(顺便说一句,它与 x86 完全不同),不幸的是我没有足够的空闲时间来找到它。

为了避免这种性能损失,您可以通过 sgen 生成序列化程序的程序集,在最终用户 PC 上的应用程序设置期间引用它并通过 ngen 编译为本机映像。

于 2010-11-09T19:48:32.463 回答
3

为了澄清“XmlSerialization.compile”这就是它正在发生的事情:

如果我们在 64 位上运行没有 .config 文件的代码,它会很慢。

如果我们将以下部分添加到应用程序的 .config 文件中

<configuration>
   <system.diagnostics>
     <switches>
        <add name="XmlSerialization.Compilation" value="4"/>
     </switches>
   </system.diagnostics>
</configuration>

结果如下:

  • 序列化程序的.cs 文件、DLL 和PDB文件保留在 temp 文件夹中
  • 序列化程序启动很快,它仍然比 32 位慢,但绝对可以接受(1-2 秒而不是 60 秒)

也许在调试模式下创建 DLL(因为有可用的 PDB 文件)会改变 JIT 编译器的行为,使其再次快速......

于 2010-11-10T08:32:39.687 回答
0

自从 64 位 .NET 发布以来,Microsoft 就知道这一点:

http://connect.microsoft.com/VisualStudio/feedback/details/508748/memory-consumption-alot-higher-on-x64-for-xslcompiledtransform-transform-then-on-x86

来自 MSFT:“x64 JIT 编译器有一些二次缩放算法。......自 2005 年首次发布 64 位框架以来,我们已经多次看到这种情况。” 和

“这个问题 a) 已知,b) 解决起来并不容易。这是 64 位 JIT 的设计问题。我们正处于替换 64 位 JIT 实施的早期阶段,所以它最终会得到解决,但不幸的是,不在 CLR 4.0 时间范围内。”

于 2013-02-21T06:39:04.860 回答