これに対する意味のある「はい」または「いいえ」の答えはありません。これは、次のような多くの要因に依存しますが、これらに限定されません。
あなたが構築しているUIの種類。
明らかに、設計しているビューの複雑さは、両方のプラットフォームでのパフォーマンスに影響します。それらには、異なるレイアウトとレンダリング パイプラインがあります。
各プラットフォームでパフォーマンスをどの程度効果的に最適化しているか。
もちろん、両方のプラットフォームでパフォーマンスの低い UI を実装するのは簡単です。複雑な UI を適切に実装するには、各プラットフォームの長所と短所を効果的に活用する方法を知る必要があります。
すぐに使用できるコントロールまたはサードパーティのコントロールを使用しているかどうか、およびそれらのコントロールの品質。
項目 1 と 2 は、サードパーティのコンポーネントにも引き継がれます。
経験豊富で有能な WinForms 開発者であれば、おそらく WinForms でパフォーマンスの高いビューを作成する方法を既に知っているでしょう。WPF の学習曲線は急勾配です。ベテランの WPF 開発者なら誰でもそれを言うことができます。また、それを使用して、パフォーマンスの高いリッチ UI を構築できることも教えてくれます。それもまた事実です。同じことが WinForms にも当てはまります。
どちらのプラットフォームも成熟しています。どちらも広く使われています。どちらも、バグ修正以外の将来の改善が見られる可能性は低い.
そうは言っても、どちらのプラットフォームにもまだ多額の投資をしていない場合は、WPF ルートに行きます。これは、優れたパフォーマンスを実現できるリッチな (重量級ではありますが) フレームワークです。パフォーマンスを向上させるために必要な作業量は、作成するビューの種類に大きく依存しますが、私は WPF を使用して大量で高頻度のデータ ビューを多数作成しました。また、WPF を使用して視覚的に豊かな戦略ゲームを作成しました。しかし、無理にそれを受け入れる必要はありません。開発者が既に WinForms の経験がある場合は、完全に実行可能なオプションです。
更新:今後数年で WinForms のサポートが .NET から削除される可能性は低いと思いますが、これが懸念される場合は、WPF を使用します。あなたが説明するビューのタイプは、WPF で簡単に作成できます。比較のために、50,000 から 500,000 行、60 列以上を表示できるいくつかのビューがあります。毎秒数千行の更新。カスタムのマルチレベルの並べ替えとグループ化が適用されます。カスタム フィルタリング; カスタム サマリー; すべて疑似リアルタイム (「人間の」リアルタイム) で最新の状態に保たれます。そのレベルのパフォーマンスを得るのは簡単ではありませんでしたが、それは可能です。説明しているデータの量と頻度は、組み込みのコントロール スイートのみを使用して、どちらのプラットフォームでも達成しやすいはずです。