“快”和“慢”是主观的，尤其是在今天的PC上。我并不是故意要让事情变慢，但在编写受控应用程序时，并没有像你想象的那么多的额外开销。 JIT等工作非常出色，可以使代码执行非常快。如果您真的需要，您还可以使用NGEN来提高启动速度。

实际上，如果你有时间学习它，你可能会考虑使用WPF而不是winform - 这是一种不同的技能集，但允许你非常好地利用图形硬件等。

此外 - .NET框架随新操作系统安装而来，并且仍然在旧操作系统中很常见。因此，对于我来说，使用C#/.NET进行开发是一个相当明显的选择。对于我来说，开发一个健壮且经过完全测试的C++应用程序（无泄漏等）所需的时间比使用C#相同要多得多。

小心不要过早优化；你提到代码的速度，但对于大多数Windows用户界面操作而言，两种方法的区别并不明显，因为绘图和磁盘访问的主要瓶颈对这两种方法来说都是一样的。

我的建议是您使用C#和WPF或WinForms作为用户界面。如果遇到一些减速情况，请使用分析工具来确定问题所在，然后考虑将一些业务逻辑替换为本地代码，但仅在有益时才这样做。

有很多可能的Windows应用程序，每个都有其自己的要求。

如果您的应用程序需要快速运行（而我所开发的应用程序就是这样），那么使用本地的C++就是一个不错的选择。

如果您的应用程序需要很小（也许是为了在慢速线路上传输），那么请使用可以使其变小的任何东西。

如果您的应用程序可能会被大量下载，您可能要警惕较新版本的.NET，因为您的用户可能还没有这些版本。

如果像大多数人一样，在它可能使用的系统上它将足够快速和小巧，就使用能让你快速和最好地开发的东西。

在几乎所有情况下，优化的正确事物是开发人员的努力。使用任何最快、最好完成高质量工作的方式。

首先..（尽管我是一个死忠的 C++ 程序员），我必须承认在速度和大小方面 C# 在大多数情况下都非常好。在某些情况下，应用程序的大小更小，因为解释部分已经在目标系统上了（请不要在这个问题上向我垃圾邮件，一个带有 dll 的应用程序比一个整合在一起的应用程序更小。Windows 只是恰好将“DLL”已经存在于那里）。

至于编码...我真的不认为有什么显著的区别。我不会花很多时间打代码。大部分时间是在思考问题。代码部分非常小。在这里保存几行代码...无足轻重，这对我来说并不是一个争论的问题...如果是的话，我会在APL中工作。学习STL、MFC和所有你所能想到的库，可能和学习C#库一样耗时。最终，它们都是一样的。

C#有一个优势。它有市场。它是最新的“热门”技能，所以有市场需求。工作很容易找到。现在记住，几年前Java是一个“热门”技能，现在每个人都在简历中面面俱到，这使得将自己定位更加困难。

好的，说了这么多..我爱C++..没有什么比真正需要时能够下手解决问题更好的感觉了。当MFC库无法胜任时，我会仔细研究它们所依赖的内容，依此类推..它是一种经典的语言，我相信它仍然是世界上使用最广泛的语言之一。Yah c++, Yah！。

Note also that most Windows computer already have .NET installed on them, so that really shouldn t be a concern.

Also, aside from the .NET installation, .NET applications tend to be quite small.

And for most application with a UI, the speed of the User is the really limiting time factor.

C# applications are slower to start than MFC applications, but you might not notice a speed difference between the two once the application is loaded.

Having no information on the application you plan to develop, I vote for WPF.

In my opinion, the requirements should help you decide the platform. What is more important: Having an application that is easily maintainable or one that must be extremely fast and small ?

A large class of applications nowadays can be written using .NET and managed code and this is in general beneficial to the development in the long term. From my experience, .NET applications are usually fast enough for most use cases and they are simpler to create. Native C++ still has its use, but just for being "faster and smaller", when "fast enough and small enough" is sufficient does not sound enough as a justification.

The speed argument between native and managed code is largely a non-issue at this point. Each release of the .NET Framework makes performance improvements over the previous ones and application performance is always a very high priority for the .NET development teams.

Starting with Windows Vista and Windows Server 2008, the .NET Framework is installed as part of the operating system. It is also part of Windows Update so almost any Windows XP system will also have it installed. If the requirement that the framework be installed on the target machine is really that much of a problem there are also compilers that will essentially embed the required runtime portions into your application to generate a single exe, but they are expensive (and in my opinion, not really worth the cost).

MFC isn t hard to learn, actually it is very easy.

Almost equal to C#.

Choice of a language or tool should be dictated by the functional and performance requirements of your project and expertise. If performance is a real consideration for you and you have done some analysis to prefer C++ over C#, then you have a decision already. Note though that having MFC based application is not terribly efficient either. On the other hand, overheads in .NET applications are over-stated.

Performance is something that is really a function of how well you write your code and what scalability requirements exist. If you would only have to work with one client with a maximum database records of 1K, then we should not be talking performance.

If ease of development and maintainability is more important, certainly C# would be the choice.

So I am not sure this is a question that can be given an answer as choice A or B with the data you have provided. You need to do the analysis of functional and non-functional requirements and decide.

Also If I use C# then the application will be slower than the native code and It reqiures .NET framework to run

An MFC app requires MFC dll s to run (and probably VC runtime as well!), so they might need to be installed, or if they are statically linked, you add to the size of the exe.

Blockquote

.NET is easier to work with. Unless you ll lose users by using it or will have trouble with code migration, you should probably use .NET. It is highly unlikely that speed will be an issue for this. Size probably doesn t matter that much, either.

Which technology are you more familiar with?

The information you gave does not include anything that would help decide. Yes, MFC apps tend to be smaller (if you include the runtime size which isn t a suitable measure in the long run), more responsive and mor costly to develop. So what?