性能关键的 GUI 应用程序（Windows、Linux）

StackOverflow https://stackoverflow.com/questions/9846

题

我的任务是更新一系列应用程序，这些应用程序是性能关键的 VB.NET 应用程序，本质上只是监视和返回网络统计数据。我只有三个要求： 将其转换为 C#，使其快速且稳定

需要注意的是，我们 “可能” 从 .NET 平台迁移到 Linux “很快”

将来我将负责维护这些应用程序，所以我想做好这件事。我决定根据 MVP 模式重构这些应用程序，以便我可以正确地对这个坏男孩进行单元测试。但我也在想，既然我使用了 MVP，我也可以在本机 C/C++ 代码中完成计算量大的事情，而 GUI 将使用 .NET 表单、Qt 或其他东西来完成。

问题：

  1. 在 winforms 中做 GUI 有意义，但在本机、非托管 C/C++ 中做昂贵的东西吗？

  2. 对于适合上述场景的良好跨平台窗口工具包有什么建议吗？

有帮助吗？

解决方案

首先，我会花一些时间尝试一些 VB.NET 到 C# 转换器. 。您基本上是在移植语法，如果不需要的话，没有理由手动执行此操作。当然，您可能需要清理转换器输出的内容，但这比手动转换要好得多。

现在，关于你的问题：

1）在 winforms 中做 GUI 有意义，但在本机、非托管 C/C++ 中做昂贵的东西吗？

还没有。等到完成转换后，再找出您实际将时间花在哪里。在您发现有必要之前，没有理由将 C/C++ 与 C# 混合在一起。您可能会发现，使用不安全的 C# 就足够了。即使这样也可能是不必要的。您可能只需要优化算法。找出你的瓶颈是什么并 然后 决定如何修复它们。

2）对于适合上述场景的良好跨平台窗口工具包有什么建议吗？

我会调查 单核细胞增多症 一定。如果您使用 C#，这确实是您能做的最好的事情。当/如果你迁移到 Linux 时，它几乎要么是单声道，要么是用另一种语言重写。

其他提示

1）过早的优化是邪恶的。用 C# 实现“昂贵的东西”，看看是否需要重构它。或者，至少设置一个测试来确定这一点。

2）哟奇。跨平台用户界面。我不会忍受“可能”的事情。把黄鼠狼钉下来；在不知道自己正在设计什么的情况下，你怎么可能做出设计决策呢？如果您采用纯 .NET 实现，如果您必须（至少）重构它才能在 Mono 中工作，他们会抱怨吗？如果您用 Java 创建它，他们是否会因为它看起来丑陋而恼火，并且用户会抱怨他们在所有这些 .jar 中找不到他们的 .exe 文件？

1）不一定。我认为更正确的说法是，无论性能影响如何，用 C++ 编写后端代码可能都是值得的。即使你不能让你的上级在平台转换上受到束缚，你还是应该为这种可能性做好准备，因为管理层往往会在没有充分理由（或警告）的情况下改变主意；即使他们现在决定不转换，也不意味着他们在六个月后不会决定转换。现在用 C++ 编写逻辑，知道这是一种可能性，尽管更困难，但可能会让您以后的生活变得更加轻松。

2）并非如此。有像 wxWindows 和 GTK# 这样的“解决方案”，但它们通常有缺陷，或者很难正常工作，或者它们在一个或另一个平台上缺少一些重要的东西。它们通常还会将您锁定在最低公分母 UI 中（即，一般控件工作正常，但您可能会忘记用它做一些有趣的事情，例如 WPF）。UI 很容易编写，所以我认为如果您用可移植的东西编写逻辑，那么将几个特定于平台的 UI 组合在一起应该是一件微不足道的事情。

对于第一个问题，很难说它是否有意义，因为这可能取决于您需要获得什么样的性能。我个人还没有看到任何由于使用 WinForms 正确设计的 GUI 中的 GUI 导致系统范围内的速度变慢，所以我不明白为什么它会导致任何问题，并且很可能它会让您的 GUI 生活更轻松。

至于你的第二个问题，如果你打算在某个时候迁移到另一个平台 - 你想看看 Mono 已经实现的库（http://www.mono-project.com/Main_Page），这也应该可以满足您在跨平台窗口方面的大部分需求，因为它支持 WinForms 和 GTK#。

不，在 C/C++ 中做“昂贵的事情”是没有意义的。与 C# 相比，潜在的（而且很可能是微小的）性能改进永远不会超过你的生产力，这是一个卑鄙、恶心的笑话。真的。还差得很远。

通读本文（以及其中引用的所有帖子）：http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

您可能想考虑使用 单核细胞增多症. 。这是 .NET 的开源版本，可以在许多平台上运行...Linux、Mac、Solaris、Windows 等。

现在关于用 C/C++ 编写昂贵的东西。这是一篇非常好的工作来解释差异的文章 C/C++ 和 C# 性能.

我再次强调，C++ 的东西非常昂贵。做我上面提到的事情有意义吗？（.NET 表单隐藏了繁重的 C++）

如前所述，我个人没有注意到由于用 VB.NET 和 C# 编写的应用程序中的 WinForms 导致任何系统范围内的速度变慢。然而，如果应用程序确实是性能密集型的，那么如果您用 C# 编写所有内容，您可能会注意到速度会稍微变慢，因为它被编译到 CIL 中（http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/）。因此，使用 C# 等语言编写 GUI 可能会使开发的这一部分变得更加容易，从而让您有更多的时间来处理代码的关键部分。这里唯一的第 22 个问题是，由于从 C# 代码调用 C/C++ 代码，可能会注意到一些速度变慢；然而，这可能性很小。

1）在 winforms 中做 GUI 有意义，但在本机、非托管 C/C++ 中做昂贵的东西吗？

很可能不会。除非您与许多其他本机 C dll 等进行通信，否则 C# 的速度可能会慢 5% 到 5% 快点 比 C++ （std::string 如果你使用它的话真的会杀了你）

2）对于适合上述场景的良好跨平台窗口工具包有什么建议吗？

如果只是一些带有按钮的简单表单，mono 很可能能够不加修改地运行它们。目前它对 .NET WinForms 的支持非常好。然而，屁股很丑:-)

我可能误解了这个问题, ，但如果是网络监控系统，为什么不写成“专用”Windows服务呢？

VB.NET 应该不会比 C# 慢很多。我不能 100% 确定生成的 IL 代码是否存在任何重大差异，但我能想到的唯一优势（以及用 C# 重写它的合理理由）（除了 C# 有更好的语法和其他一些好处） ）是使用不安全的代码块，可以稍微加快速度。

c/c++ 的东西最终可能是一个好主意，但现在是 YAGNI。与 Linux 的东西相同。忽略它， 你不会需要它 直到你需要它。收下 简单的. 。正如你所说，单元测试该死的。让代码正常运行并 改进设计 从那里。

我曾经遇到过类似的困境，当时我试图找到一种最佳方法来开发基于 PC 的硬件测试工具（这显然意味着“带有 UI 选项”），该工具与嵌入式硬件（通过 PCMCIA 接口）进行交互。

瓶颈在于测试运行的最大偏差应与测试人员指定的预期时间相差 10 毫秒。

例如：如果测试人员创建以下测试序列：

    1.远程激活硬件
    2.等待50ms延迟。
    3.读取硬件信息。

步骤2中提到的延迟不应> 60ms。


我选择C++ WIN32应用程序作为我的后端，并选择VC++ 2005 Winform（.NET平台）进行UI开发。有关如何连接这两者的详细信息，请参阅 msdn
我这样隔离系统：
在 VC++.NET 中：

    1.UI 具有有关硬件的完整信息（通过后端应用程序读取）并按需控制硬件。（按钮、组合框等..ETC..）
    2.用于运行时间关键测试序列的 UI（如上面的示例中所述）。
    3.收集这些信息并以时间线性格式（即，按照必须执行的步骤的精确顺序）构建流（文件流）。
    4.与WIN32后端应用程序的触发和握手机制（通过重定向标准输入和标准输出）。公共资源是文件流。

在 C++ WIN32 中：

    1.解释输入文件流。
    2.与硬件的交互。
    3.从硬件收集信息并将其放入输出文件流中。
    4.向 UI 指示测试完成情况（通过重定向的标准输出）。

完整的系统已启动并运行。看起来好像还蛮稳定的。（没有上面提到的时序偏差）。
请注意，我们使用的测试 PC 仅用于硬件测试目的（它只运行 UI，没有自动更新、病毒扫描等功能。）ETC..）。

gtk 夏普 是一个非常好的跨平台工具包。

Gtk# 是一个用于 mono 和 .Net 的图形用户界面工具包。该项目绑定了 gtk+ 工具包和各种 GNOME 库，支持使用 Mono 和 .Net 开发框架进行完全原生的图形 Gnome 应用程序开发。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top