WPFとWinformsの間にパフォーマンスの違いはありますか？
タイトルはほとんどすべてを語っています。私はいくつかグーグルを行いましたが、私が見つけることができる唯一の情報は少なくとも1年前のものであり、その情報の一部はWindows 7より古いものです。
WinFormsで一緒にハッキングする必要があるものよりも（データバインディングなど）の方が速く動作しますか？
これは、誰にとっても重要な場合に備えて、.NETで作成されたプロジェクトになります。
[〜＃〜]編集[〜＃〜]
私が見ているこのプロジェクトは、基本的なスタイルのUIを持っていますが、多くの情報が表示される可能性があります（ファイル/ディレクトリを照会して画面に表示します）。画面を自動更新するかどうかはまだ決めていませんが、そうかもしれません。
かなりの量のコントロールが存在する可能性がありますが、だれでも「グラフィック」集約型と見なすべきものはありません。
次に、パフォーマンスをビジネスアプリケーションの観点から見ています。
サードパーティのコントロールを使用する予定はありません。
これに対する意味のある「はい」または「いいえ」の答えはありません。これは、次のような多くの要因に依存しますが、これらに限定されません。
作成しているUIの種類。
明らかに、設計しているビューの複雑さは、両方のプラットフォームでのパフォーマンスに影響します。レイアウトとレンダリングパイプラインが異なります。
各プラットフォームのパフォーマンスをどの程度効果的に最適化するか。
もちろん、両方のプラットフォームでパフォーマンスの低いUIを実装するのは簡単です。非常にうまく機能するように複雑なUIを実装するには、各プラットフォームの長所と短所を効果的に活用する方法を知る必要があります。
すぐに使えるコントロールとサードパーティのコントロールのどちらを使用しているか、およびそれらのコントロールの品質。
アイテム1と2は、サードパーティのコンポーネントにも引き継がれます。
あなたが経験豊富で有能なWinForms開発者であれば、おそらくWinFormsでパフォーマンスの高いビューを作成する方法をすでに知っています。 WPFの学習曲線は急です。ベテランのWPF開発者なら誰でもそれを知ることができます。また、これを使用してパフォーマンスの高いリッチUIを構築できることもわかります。それも本当です。 WinFormsについても同様です。
どちらのプラットフォームも成熟しています。どちらも広く使用されています。どちらも、バグ修正以外に将来の改善は見られません。
いずれにしても、どちらのプラットフォームにもまだ多額の投資をしていない場合は、WPFルートを使用します。これは、（ヘビーウェイトではありますが）リッチなフレームワークであり、パフォーマンスを高めることができます。これを適切に実行するために必要な労力は、作成するビューのタイプに大きく依存しますが、私は、WPFを使用して大量の高頻度データビューを多数構築しました。また、WPFを使用して視覚的に豊かな戦略ゲームを構築しました。しかし、それに伴うcompelledを感じないでください。開発者が既にWinFormsの経験がある場合でも、完全に実行可能なオプションです。
pdate：今後数年間でWinFormsのサポートが.NETから削除される可能性は低いと思いますが、これが懸念される場合は、WPFを使用します。説明するビューのタイプは、WPFで簡単に作成できます。比較のために、50,000以上から500,000までの行と60以上の列を表示できるいくつかのビューがあります。 1秒あたり数千行の更新。カスタムのマルチレベルの並べ替えとグループ化が適用されます。カスタムフィルタリング;カスタムサマリー。すべてが疑似リアルタイム（「人間」のリアルタイム）で最新に保たれました。そのレベルのパフォーマンスを得ることは容易ではありませんでしたが、それは可能です。記述しているデータの量と頻度は、どちらのプラットフォームでも、組み込みのコントロールスイートのみを使用すると、かなり簡単に実現できます。
複雑なUIを実行している場合は、WPFが適しています。 winformsは何もサポートしていません。
単純なUIを実行している場合は、WPFが適しています。
- すべての手続き型のwinformsアプローチでは、コードがあまりにもひどいため、はるかにクリーンなパターン（MVVM）が可能になります。
- DataBinding機能がはるかに優れています。
- 何かをカスタマイズする必要がある場合は、canできます。
- I Virtualization が組み込まれています。
- デフォルトでは、解像度に依存しません。
長期的な懸念がある場合：
WPFを使用する方法です。現在/将来のWindows UIフレームワークはWinRT XAMLです。 winformsアプリよりも、WPFアプリをWinRT XAMLに移植する方がはるかに簡単です。また、MVVMは本当にテクノロジーにとらわれないため、最終的には他のUIテクノロジーでViewModelを再利用できます。
編集：私は多くの反対投票を受けており、この回答に関して多くの議論があるので、私は特にOPの質問に焦点を当てて、むしろ客観的な答えを提供しようとする：
パフォーマンス：WPFのメモリ使用量を、非常に単純なUI（WindowまたはFormTextBoxたとえば）、WPFはwinformsよりもはるかに多くのメモリを消費するようです。これは、WPFフレームワークがwinformsよりもはるかに大きいため、機能するために「ロードするもの」がはるかに多いという事実によるものです。これは、コールドスタートアップ時間を比較する場合にも当てはまります（ここでも、1つの制御の状況で）。
対照的に、いくつかのコントロール、ボタン、データグリッド、コンボボックス、テキストボックスなどで構成されるより重いUIを作成する場合（ビジネスアプリケーションで実際に一般的なもの）、WPFを支持するまで違いが小さくなります。これは、WPFの DependencyProperty システムがデフォルトのプロパティ値をインスタンスごとではなく単一のメモリ空間に格納するためです。
WPFは最初から複雑な/リッチUIに使用することを目的としており、1つのコントロールのケースではなく、何千ものコントロールがある状況で機能するように最適化されています。
データ中心の観点からWPFとwinformsのパフォーマンスを比較する際に考慮すべきもう1つの非常に重要な側面は、前述のように、 I Virtualization です。 this Video を見るだけで、ListBoxに2万行を表示する必要がある状況でWPFのパフォーマンスが大幅に向上することが明らかになります。 winformsの第一人者から言われた winformsもサポートしているようですが、winformsが適切にサポートしていないため、P/Invokeの呼び出しに頼る必要があります。 ListBox以外の他のコントロールもwinformsでそれをサポートしているかどうか（DataGridViewやTreeViewなど）は私には明らかです。すべてのWPF ItemsControlsは、すでに存在するか、デフォルトでいくつかの単純なアプリケーション全体のスタイルで仮想化できます。
ハードウェアアクセラレーション：「これは必要ない」と思うかもしれませんが、見回すと、UIの更新時にwinformsがひどくちらつき始める場合があり、必ずしも複雑な描画状況ではなく、多くのコントロールを含むウィンドウ。これを回避する方法はいくつかありますが、ビジネスロジックに集中する代わりに、最初から考えてはいけない問題を修正するために時間を浪費し始めなければなりません。 WPFでは、ハードウェアアクセラレーションだけでなく、ビットマップベースではなくベクターベースであるため、この問題が発生することはありません。
結論：1コントロールの場合はwinformsの方がパフォーマンスが向上する可能性がありますが、WPFは実際のデータ中心のUIのすべてのレベルで明らかに勝者です。
これだけでなく、@ Blamによって言及されているように、テクノロジーを選択するには、パフォーマンスの側面だけでなくスケーラビリティ、カスタマイズ可能性、保守性、開発の容易さ、長期的な視点、その他多数。
これらすべての点で、WPFは明らかに勝者です。適切に設計されたWPF MVVMアプリケーションには、本当にクリーンで簡潔な美しいコードベースがあります。 winformsは、どの程度熟練していても、複雑なシナリオをサポートしておらず、考えられるほとんどすべてのカスタムコードが必要であるため、常にソリューションの背後にある汚いコードを強制します。
特にカスタマイズ性については、notを作成して Completely Custom、Rich UI を作成する計画を立てても、WPFを選択する方がはるかに賢明です。 データをデフォルトでサポートされていない形式で表示する 。次に、「所有者描画」などの恐ろしいテクニックで苦しみ、時間を失うことから始めなければなりませんが、WPFでは必要なのは単純な DataTemplate だけです。
確かに、WPFは複雑なフレームワークですが、急な学習曲線を作成するのは実際にはその複雑さではなく、むしろ必要な 精神の変化 は、他のフレームワークから来ているほとんどの開発者が実際に苦労していることです。
また、上記のように、特定のクラスのセットではなく、抽象化に対してコーディングすることが重要です。これにより、コードは必要に応じて最終的に他のフレームワークに移植できるようになります。 WPFではそれが可能ですが、winformsではできません。
Winformsでコーディングすると、winformsの機能やハッキングの背後にあるコードで永遠に行き詰まってしまいます。 winformsでMVPを使用する場合、これは多少緩和されますが、プレゼンターは、UIフレームワークと完全にUIに依存しないMVVMのViewModelsよりもはるかに緊密に連携しています。
XAMLとMVVMを使用してWPFでコーディングする場合、最終的にはWPF XAMLビューを別のものに置き換え、ViewModelをそのまま維持することができます。つまり、ViewModels are ビューではなくアプリケーション。
WPFを使用してパネルに大量の線を描画し、WPFを使用してキャンバスに同じdtを描画してみたところ、Winformが1秒未満でドリューを作成したことがわかりました。 shpesより
WindowsフォームとWPFの両方について、多数のアプリケーションをMVVMパターンでコーディングしました。両方に実装された同じアプリケーションを比較すると、データバインドされたアプリケーションのWindowsフォームが優先されます。単一の親データグリッドまたは構造にバインドされた複数の子データグリッドがある場合、その影響はさらにわかりますが、その理由はわかりません。そのため、ビジネスアプリケーションでは、必要な場合にのみ、常にWPFでコーディングします。また、並べ替えやフィルタリングもWindowsフォームの方が簡単です。