【问题标题】:Troubles of performance related to WPF control hosted in WinForms与 WinForms 中托管的 WPF 控件相关的性能问题
【发布时间】:2014-04-03 15:08:56
【问题描述】:

我们有一个非常复杂的软件,主要使用 C# 中的 .NET WinForms 编写。许多人为此做出了贡献。其中一项贡献是在 Win Forms 中添加了一个 Windows Presentation Foundation (WPF) 控件。该控件被认为是一种通用控件,在应用中的很多地方都会用到。

直到几天前,当我们开始看到启动应用程序出现过度延迟时,一切都运行良好。该应用程序过去不到 5 分钟即可启动,但现在需要 20 分钟才能启动。

我们一直在分析情况,但发现很难确定真正的问题。我们已经看到,我们在多个地方使用的行为不端的公共控件最终会调用以下框架函数:

系统功能执行其职责所花费的时间如上图所示。每次初始化公共控件时,系统功能大约需要 1.5 分钟。我们在应用程序中至少使用了 8 次通用控件。所以,总共 12 分钟。

有没有其他人看到 WinForms 上托管的 WPF 控件存在此类问题? 任何帮助将不胜感激。

编辑:

我们使用的 C# 字典存在问题。通过使用 List 摆脱它可以解决延迟问题。微软在他们的最后重现了这个问题。他们正在努力。 也许,我们的应用程序将 C# Dictionary 发挥到了极致;)

感谢大家提供意见。

【问题讨论】:

  • 您能发布您的 WPF 控件代码吗? XAML / 代码隐藏。

标签: c# .net wpf winforms performance


【解决方案1】:

这很可能是 WPF 控件的初始化,而不是与 ElementHost 或它托管在 WinForms 中的事实有关。

如果没有看到 WPF UserControl 的代码,很难告诉你这可能是什么,但我会说 WPF / WinForms 的互操作肯定是一个红鲱鱼。

【讨论】:

  • 我现在无法访问代码。但我会尽快发布。
【解决方案2】:

您可以尝试使用Ngen:

The Native Image Generator (Ngen.exe)是一种提高托管应用程序性能的工具。 Ngen.exe 创建本机映像,这些文件包含已编译的特定于处理器的机器代码,并将它们安装到本地计算机上的本机映像缓存中。运行时可以使用缓存中的本机图像,而不是使用just-in-time (JIT) compiler 来编译原始程序集。

如果项目的程序集将在Ngen的帮助下编译,则无需在启动应用程序和加载使用程序集的元数据之前每次运行JIT-compiler。

Ngen 将找到主程序集的所有静态依赖并将它们全部编译到低级映像中。这些图像将存储在程序集缓存 (GAC) 中,从而可以减少应用程序加载时间。

【讨论】:

    猜你喜欢
    • 2013-05-29
    • 1970-01-01
    • 1970-01-01
    • 2011-03-03
    • 1970-01-01
    • 1970-01-01
    • 2016-10-29
    • 2012-03-27
    • 1970-01-01
    相关资源
    最近更新 更多