5

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

一个警告是，我们“可能” “很快”从 .NET 平台迁移到 linux

我将来会负责维护这些应用程序，所以我想把这件事做好。我决定根据 MVP 模式重构这些应用程序，以便我可以正确地对这个坏男孩进行单元测试。但我也在考虑，因为我使用的是 MVP，我也可以在原生 C/C++ 代码中执行计算成本高昂的工作，而 GUI 可以使用 .NET 表单或 Qt 或其他方式完成。

问题：

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

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

4

12 回答 12

5

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

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

于 2008-08-13T14:19:25.633 回答
5

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

现在，至于你的问题：

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

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

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

我肯定会研究单声道。如果您使用 C#，这确实是您能做的最好的事情。当/如果您迁移到 Linux 时，它几乎是单声道或另一种语言的另一种重写。

于 2008-08-13T19:47:04.350 回答
3

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

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

于 2008-08-13T14:28:51.760 回答
2

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

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

于 2008-08-13T14:24:12.287 回答
2

不，在 C/C++ 中做“昂贵的东西”是没有意义的。与 C# 相比，潜在的（并且很可能是次要的）性能改进永远不会超过你的生产力，因为它是一个卑鄙的、病态的笑话。真的。它甚至不接近。

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

于 2008-08-13T14:27:41.997 回答
2

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

现在关于用 C/C++ 编写昂贵的东西。这是一篇很好地解释了C/C++ 和 C# 性能之间的差异的文章。

于 2008-08-13T14:34:47.740 回答
1

再一次，让我强调一下，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++ 代码而导致的一些减速；但是，这很可能不太可能。

于 2008-08-13T19:13:50.580 回答
1

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

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

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

如果只是一些带有按钮的简单表单，mono 可能无需修改即可运行它们。如今，它对 .NET WinForms 的支持非常好。然而，它是丑陋的:-)

于 2008-08-13T20:34:21.353 回答
0

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

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

于 2008-08-13T19:32:12.570 回答
0

gtk-sharp是一个非常不错的跨平台工具包。

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

于 2008-09-17T14:41:08.820 回答
0

c/c++ 的东西最终可能是个好主意，但现在是 YAGNI。与Linux的东西一样。忽略它，除非你需要它，否则你不会需要它。保持简单。正如你所说，单元测试彻底搞砸了。让代码工作并从那里改进设计。

于 2008-10-01T21:23:35.703 回答
0

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

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

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

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

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


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

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

在 C++ WIN32 中：

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

整个系统已启动并运行。它似乎很稳定。（没有上面提到的时序偏差）。
请注意，我们使用的测试 PC 仅用于硬件测试目的（它只运行 UI，没有自动更新、病毒扫描等.. 等等）。

于 2009-11-09T08:50:29.053 回答