标题基本概括了所有内容。我做了一些谷歌搜索，但我能找到的唯一信息至少有一年的历史，有些信息比 Windows 7 更早。所以我很好奇，使用 WPF 是否会降低性能？
它对某些东西（例如数据绑定）的工作速度是否比你必须在 WinForms 上一起破解的速度更快？
这将是一个使用 .NET 创建的项目，以防万一这对任何人都很重要。
编辑
我正在查看的这个项目将具有基本的 UI 样式，但是可能会显示很多信息（它正在查询文件/目录并将它们显示在屏幕上）。我还没有决定它是否会自动刷新屏幕，但我想它可能会。
可能会有相当多的控制，但是没有人应该认为是“图形”密集的。
然后我从业务应用程序的角度来看待性能。
我不打算使用第 3 方控件。
如果您正在做复杂的用户界面，WPF 是要走的路。winforms 不支持任何东西。
如果您正在做简单的用户界面，WPF 是要走的路，因为：
如果您担心长期问题：
WPF是要走的路。当前/未来的 Windows UI 框架是 WinRT XAML。最终将您的 WPF 应用程序移植到 WinRT XAML 比 winforms 应用程序要容易得多。而且，由于 MVVM 确实与技术无关，您最终可以在任何其他 UI 技术中重用您的 ViewModel。
编辑：由于我收到了很多反对票，并且围绕这个答案进行了很多讨论，所以我将特别关注 OP 的问题并尝试提供一个相当客观的答案：
性能：当您将 WPF 的内存使用情况与真正简单的 UI（例如 aWindow或Form仅包含 a TextBox）的 winforms 进行比较时，WPF 似乎比 winforms 消耗更多的内存。这是因为 WPF 框架比 winforms 大得多，因此它有更多的“要加载的东西”才能工作。当您比较冷启动时间时也是如此（同样，在 1-control 情况下）。
相反，当您创建由多个控件/按钮/数据网格/组合框/文本框/等（业务应用程序中真正常见的东西）组成的较重的 UI 时，差异开始缩小，直到它甚至有利于 WPF。这是因为 WPF 的DependencyProperty系统将默认属性值存储在单个内存空间中，而不是基于每个实例。
WPF 从一开始就旨在用于复杂/丰富的 UI，并经过优化以处理有数千个控件的情况，而不是 1 个控件的情况。
从以数据为中心的角度比较 WPF 和 winforms 之间的性能时，另一个非常重要的方面是，如上所述，UI 虚拟化。只需查看此视频，就可以明显看出 WPF 在您需要在ListBox. winforms 大师告诉我，winforms 似乎也支持这一点，但是由于 winforms 没有正确支持这一点，您需要求助于称为 P/Invoke，而且从他所说的情况来看，如果其他控件除外，我并不明显ListBox 也支持 winforms（例如DataGridViewand TreeView）。默认情况下，所有 WPFItemsControls都已经或可以使用一些简单的应用程序范围样式虚拟化。
硬件加速：你可能会想“我不需要这个”，但如果你环顾四周，在更新 UI 时，winforms 会开始可怕地闪烁的情况有数千种，不一定是在复杂的绘图情况下，在调整大小时也会如此。包含许多控件的窗口。有一些方法可以解决这个问题，但话又说回来，您将不得不开始浪费时间来解决您永远不必开始的问题，而不是专注于您的业务逻辑。WPF 永远不会有这个问题，不仅因为它是硬件加速的，还因为它是基于矢量的，而不是基于位图的。
结论：虽然 winforms 在 1-control 情况下可能表现更好，但 WPF 在现实世界的数据中心 UI 的所有级别上都是明显的赢家。
除此之外，正如@Blam 所提到的，选择一种技术不仅需要分析性能方面，还需要分析可扩展性、可定制性、可维护性、易于开发、长期视角等等。
在所有这些方面，WPF 再次成为明显的赢家。一个设计良好的 WPF MVVM 应用程序有一个非常干净、简洁、漂亮的代码库。winforms，无论你对它有多熟练，总是会强迫你在解决方案后面使用脏代码，这仅仅是因为它不支持真正复杂的场景，并且几乎所有可以想到的东西都需要自定义代码。
特别是可定制性，我会说即使您确实not计划创建一个完全自定义的丰富 UI，选择 WPF 仍然是一个更明智的决定，因为使用 winforms，如果您想显示您的默认情况下不支持的格式的数据。然后，您将不得不开始遭受诸如“所有者绘制”之类的可怕技术的痛苦和浪费时间，而在 WPF 中，您所需要的只是一个简单的DataTemplate
诚然，WPF 是一个复杂的框架，但实际上并不是它的复杂性导致了陡峭的学习曲线，而是所需的心态改变确实是大多数来自其他框架的开发人员所苦苦挣扎的问题。
而且，如上所述，重要的是您针对抽象而不是针对一组特定的类进行编码，以便您的代码最终可以在需要时移植到其他框架。WPF 允许这样做，而 winforms 则不允许。
如果您在 winforms 上编码，您将永远陷入 winforms 的无能和黑客背后的代码。确实，如果您在 winforms 上使用 MVP，这会有所缓解，但 Presenter 与 UI 框架的耦合仍然比 MVVM 中的 ViewModel 更紧密，后者完全与 UI 无关。
如果您在 WPF 中使用 XAML 和 MVVM 进行编码，您最终可以将 WPF XAML 视图替换为其他内容，并保持您的 ViewModel 不受影响，这意味着您实际上不必从头开始重写整个应用程序，因为 ViewModel是应用程序，不是意见。
对此没有有意义的“是”或“否”答案。这取决于许多因素，包括但当然不限于：
你正在构建什么样的用户界面。
显然，您正在设计的视图的复杂性将影响两个平台的性能。它们有不同的布局和渲染管道。
您在每个平台上优化性能的效率如何。
当然，在两个平台上实现性能不佳的 UI 是很容易的。实现一个复杂的 UI 以使其性能非常好，需要知道如何有效地利用每个平台的优势和劣势。
无论您使用的是开箱即用控件还是第三方控件，以及这些控件的质量。
第 1 项和第 2 项也适用于任何第三方组件。
如果您是一位经验丰富且称职的 WinForms 开发人员，那么您可能已经知道如何在 WinForms 中创建高性能视图。WPF 的学习曲线很陡峭；任何经验丰富的 WPF 开发人员都可以告诉您。他们还会告诉您，您可以使用它来构建性能良好的丰富 UI。这也是真的。WinForms 也是如此。
两个平台都很成熟。两者都被广泛使用。除了错误修复之外，两者都不太可能看到任何未来的改进。
综上所述，如果您还没有在这两个平台上投入巨资，我会选择 WPF 路线。它是一个丰富的（尽管是重量级的）框架，可以很好地执行。使其表现良好所需的工作量很大程度上取决于您正在创建的视图类型，但我已经使用 WPF 构建了许多高容量、高频率的数据视图。我还用 WPF 构建了一个视觉丰富的策略游戏。但不要觉得被迫接受它；如果您的开发人员已经使用过 WinForms，那么它仍然是一个完全可行的选择。
更新：我认为 WinForms 支持在未来几年内不太可能从 .NET 中删除，但如果这是一个问题，那么我会选择 WPF。您描述的视图类型可以很容易地在 WPF 中创建。作为比较，我有几个视图能够显示 50,000 到 500,000 行和 60 多列；每秒数千行更新；应用自定义、多级排序和分组；自定义过滤；自定义摘要；全部以伪实时（“人类”实时）保持最新。获得这样的性能水平并不容易，但可以做到。您所描述的数据量和频率应该在任一平台上都更容易实现，并且只使用内置的控制套件。
我尝试在 winforms 的面板上绘制大量线条，并在使用 WPF 的画布上绘制相同的 dt，发现 winforms 在不到一秒的时间内创建了绘图，而 WPF 花了很多秒，即使我在 WPF 中使用 Pathgeometry 而不是比 shpes
我已经为 Windows 窗体和 WPF 编写了许多 MVVM 模式的应用程序，当您比较在两者上实现的相同应用程序时，Windows 窗体在数据绑定应用程序中胜出。如果您有多个子数据网格绑定到单个父数据网格或结构，您会注意到影响更大，永远不明白为什么。因此，对于业务应用程序，我总是只在必要时才在 WPF 中编码。我还发现在 Windows 窗体上排序和过滤也更容易。