从MFC进行时间关键应用程序迁移 [英] Time Critical Application Migration from MFC

问题描述

我有一个在标准PC主板上运行的多线程Windows桌面应用程序。它从相机收集图像，将它们显示在UI上，对这些图像执行图像处理，还将结果显示在UI上，并通过串行端口将信息发送到PLC以控制外部组件。这是一个时间关键系统，每隔约50ms重复这一系列步骤。有时，在进行所有计算的同时，存在大量的用户交互。总之，标准操作涉及app运行，图像被收集，分析，结果显示在GUI上并与PLC通信。



遗留代码为100％ MFC 6.0。



主要目标是升级GUI - 不牺牲当前速度。



1.What有关重建/升级此应用程序的一些建议吗？

2. WPF前端/ C＃后端是否可以工作，并且和传统一样快？

3.Windows Form前端/ C＃后端是否可以工作，并且和传统一样快？

4.Windows Form前端/ C ++后端是否可以工作，并且与传统一样快？

5.如果只是将应用程序升级到MFC 11，那么前3个选项将如何比较？

6.如何转向托管框架会影响速度和可重复性？


任何想法都将不胜感激！



如果这个应用程序不是时间关键，我会去C＃。我担心通过升级GUI和转移到托管代码，我会牺牲速度。在做出这个决定之前能够确定风险是很棒的。

I have a multi-threaded windows desktop application that runs on a standard PC motherboard. It collects images from cameras , displays them onto the UI, performs image processing on these pictures, also displays the results onto the UI and sends information via the Serial port to the PLC to control an external component. It’s a time critical system that repeats this sequence of steps every ~ 50ms. At times, there is a fair amount of user interaction while all of the computations are going on. In summary, standard operation involves app running with the images being collected , analyzed, results being displayed on the GUI and communicating with the PLC.

The legacy code is 100% MFC 6.0.

The main goal is to upgrade the GUI – without sacrificing the current speed.

1.What are some recommendations on rebuilding/upgrading this application?
2.Would a WPF front end / C# back end work, and be as fast as legacy?
3.Would a Windows Form front end / C# back end work, and be as fast as legacy?
4.Would a Windows Form front end / C++ back end work, and be as fast as legacy?
5.How would the 1st 3 options compare to simply upgrading the app to MFC 11
6.How will moving to a managed framework affect speed and repeatability?

Any thoughts would be greatly appreciated!

If this app were not time critical, I would go to C#. I’m concerned that by upgrading the GUI and by moving to managed code, I’m sacrificing speed. It’d be great to be able to ascertain the risk before making this decision.

推荐答案

假设'代码重用'不是必需的（否则你可能已经按照 MFC 11 迁移路径），我会对完全管理的路径进行一些测试（即所有 C＃）使用选项 4 （即 C＃GUI ， C ++ 计划B。时间关键组件。

Assuming 'code reusing' is not a requirement (otherwise you probably would have already followed the MFC 11 migration path), I would do some tests toward the fully managed path (that is all C#) with option 4 (that is C# GUI, C++ for time critical components) as plan B.

我更赞同解决方案2.我的答案：



1. 快速问题&对于如此广泛的问题，答案可能不是最合适的地方，但主要想法可能是：不要假设你迁移;您从头开始创建系统，因为技术非常不同。将其视为一个好处：您可以正确构建新系统，而不是复制旧错误。



2-3。这取决于旧应用程序的好坏。其他答案给你一些想法。



4.我不会在前端和后端之间绘制C ++和.NET之间的界限。一般情况下，它不会给你任何好处。相反，您可以尝试保留C ++作品，这些作品肯定写得很好，特别是效率非常高。比如，如果您创建了非常快速的C ++图像处理，您可以在显示.NET UI中的处理结果时使用它。对于互操作性，您可以使用P / Invoke，但使用C ++ / CLI会更好，这是一种标准化语言（在ECMA 372下;请参阅下面的链接）。您可以利用创建混合模式（托管+非托管）C ++ / CLI项目的可能性，在托管和非托管之间实现非常平滑的边界。请参阅：

http://en.wikipedia.org/wiki/C ％2B％2B / CLI [ ^ ]，

http：//www.ecma-international .org / publications / standards / Ecma-372.htm [ ^ ]，

http：// www.gotw.ca/publications/C++CLIRationale.pdf [ ^ ]，

http：// msdn.microsoft.com/en-us/library/xey702bw.aspx [ ^ ]。



5。 没门。请参阅上文。



6.重复性是多少？一切都写得正确，没有竞争条件，只有时间可以是不可重复的，而不是逻辑。时间取决于许多因素;所以不可能给出一个简短的答案。同样，你可以用更快的C ++代码填补瓶颈，但这一切都取决于它是如何设计的;许多人设法使用C ++创建更慢的代码...不要忘记，特别是，你也可以通过使用NGEN消除.NET JIT延迟。请参阅：

http://en.wikipedia.org/wiki/Just-in -time_compilation [ ^ ]，

http://msdn.microsoft.com/en-us/magazine/cc163610 .aspx [ ^ ] 。

-SA

I rather agree with Solution 2. My answers:

1. Quick Questions & Answer might be not the most suitable place for such a wide problem, but main idea could be: don't assume you migrate; you create the system from scratch, because the technologies are very different. Consider it as a benefit: you can build new system properly, not replicating old mistakes.

2-3. It depends on how good or bad old application was. Other answers give you some ideas.

4. I would not draw the boundary between C++ and .NET between front and back end. In general case, it won't give you any benefits. Rather, you can try to leave C++ pieces which are certainly well written, in particular, with very good efficiency. Say, if you created very fast C++ image processing, your can use it while showing the result of processing in .NET UI. For interoperability, you can use P/Invoke, but it would be much better to use C++/CLI, which is a standardize language (under ECMA 372; please see the links below). You can utilize the possibility of creation of mixed-mode (managed+unmanaged) C++/CLI project with really smooth boundary between managed and unmanaged. Please see:
http://en.wikipedia.org/wiki/C%2B%2B/CLI[^],
http://www.ecma-international.org/publications/standards/Ecma-372.htm[^],
http://www.gotw.ca/publications/C++CLIRationale.pdf[^],
http://msdn.microsoft.com/en-us/library/xey702bw.aspx[^].

5. No way. Please see above.

6. What repeatability? It everything is written correctly, without race conditions, only timing can be non-repeatable, not logic. Timing depends on many factors; so it's impossible to give one short answer. Again, you can fill bottlenecks with faster C++ code, but it all depends on how it's all engineered; many managed to create much slower code with C++… Don't forget that, in particular, you can also go away for .NET JIT delays by using NGEN. Please see:
http://en.wikipedia.org/wiki/Just-in-time_compilation[^],
http://msdn.microsoft.com/en-us/magazine/cc163610.aspx[^].

—SA

这取决于核心实现的耦合程度用你的UI。例如，如果您使用窗口处理窗口的窗口处理，在您的核心代码中（不是推荐的模式，但我已经看到了这样的实现），使用新平台创建UI可能需要更改核心实施也是如此。除此之外，虽然渲染Windows窗体的底层模型与该问题中的MFC相同（取决于Windows句柄），但在WPF中它完全不同（取决于DirectX）。因此，在这种情况下，可以从选项列表中删除WPF。

It's depends on how much your core implementation is coupled with your UI. For instance, if you use a window handle to the window that the graphic should be paint on, in your core code (not a recommended pattern but, I already saw an implementation like this), creating UI with a new platform can require changes in the core implementation too. In addition to that, while the underlying model of rendering the Windows Form is same as MFC in that issue (depends on windows handles), in WPF it's completely different (depends on DirectX). So, in that case, WPF may be removed from the options list.

但是，如果您的UI完全与核心分离，则可以使用C ++实现核心实现并为其编写WPF UI。有关将C ++实现包装为与C＃代码一起使用的更多详细信息，您可以阅读我的CP文章：将本机暴露给托管 - C ++ / CLI与P / Invoke 。

But, if your UI is completely decoupled form your core, you can keep your core implemented with C++ and, write a WPF UI for it. For more details about wrapping C++ implementation to be used with C# code, you can read my CP article about: Exposing native to managed - C++/CLI vs. P/Invoke.

这篇关于从MFC进行时间关键应用程序迁移的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！