パフォーマンスが重要な GUI アプリケーション (Windows、Linux)

https://stackoverflow.com/questions/9846

08-06-2019
|

質問

私は、基本的にネットワーク統計を監視して返すだけの、パフォーマンスが重要な VB.NET アプリである一連のアプリケーションを更新する任務を負っています。要件は 3 つだけです。 C# に変換して高速化し、安定させます。

1 つの注意点は、 "5月" .NET プラットフォームから Linux に移行する "すぐ"

将来的には私がこれらのアプリのメンテナンスを担当することになるので、しっかりと管理していきたいと思っています。この悪い奴らを徹底的に単体テストできるように、MVP パターンに従ってこれらのアプリをリファクタリングすることにしました。しかし、MVP を使用していたときから、GUI を .NET フォームや Qt などで実行しながら、計算量の多い処理をネイティブ C/C++ コードで実行できるのではないかとも考えていました。

質問:

winforms で GUI を実行するのに、高価な作業をネイティブのアンマネージド C/C++ で実行するのは意味があるのでしょうか?
上記のシナリオに適した、優れたクロスプラットフォームウィンドウキットに関する推奨事項はありますか?

解決

まずは時間をかけていくつか試してみます VB.NET から C# へのコンバーター. 。基本的には構文を移植することになりますが、必要がない場合は手動で行う必要はありません。確かに、コンバーターから出力されたものをクリーンアップする必要があるかもしれませんが、手動で変換するよりもはるかに優れています。

さて、ご質問については次のとおりです。

1) winforms で GUI を実行し、高価な作業をネイティブのアンマネージド C/C++ で実行するのは理にかなっていますか?

まだ。変換が完了するまで待ってから、実際にどこに時間を費やしているかを確認してください。必要であることがわかるまで、C/C++ と C# を混合することに飛びつく理由はありません。安全でない C# にドロップするだけで十分であることがわかるかもしれません。それさえも不要かもしれない。アルゴリズムを最適化する必要があるだけかもしれません。何がボトルネックになっているのかを見つけて、 それから それらを修正する方法を決定します。

2) 上記のシナリオに適した、優れたクロスプラットフォームウィンドウキットに関する推奨事項はありますか?

調べてみたいと思います単核症確かに。C# を使用する場合、これが実際にできる最善の方法です。Linux に移行する場合、モノラルか、別の言語で書き直すことになります。

他のヒント

1) 時期尚早な最適化は悪です。「高価なもの」を C# で実装し、リファクタリングが必要かどうかを確認してください。あるいは、少なくともこれを判断できるテストを設定してください。

2) よっち。クロスプラットフォームUI。私は「かもしれない」ものには我慢しません。イタチを釘付けにしてください。自分が何をデザインしているのかを知らずに、どうやってデザインの決定を下すことができるでしょうか?純粋な .NET 実装を使用する場合、Mono で動作するように (少なくとも) リファクタリングする必要がある場合、文句を言われるでしょうか?これを Java で作成した場合、見た目が非常に醜いことにユーザーはイライラし、ユーザーはすべての .jar の中に .exe ファイルが見つからないと不満を言うのでしょうか?

1) 必ずしもそうとは限りません。パフォーマンスへの影響に関係なく、バックエンドコードを C++ で記述することはおそらく価値があると言ったほうが正しいと思います。プラットフォームの切り替えに関して上層部を縛り付けることはできませんが、その不測の事態に備えて準備をしておくことは賢明です。なぜなら、管理職は正当な理由 (または警告) なしに考えを大きく変える傾向があるからです。たとえ今は切り替えないと決めたとしても、6 か月後に切り替えないとは限りません。より困難ではあるものの可能性があることを知って、今すぐ C++ でロジックを作成しておくと、後で作業が大幅に楽になる可能性があります。

2) そうではありません。wxWindows や GTK# のような「ソリューション」はありますが、多くの場合、バグが多かったり、適切に動作させるのが困難であったり、プラットフォームによっては重要なものが欠けていたりします。また、これらは通常、ユーザーを最小公倍数の UI に閉じ込めてしまいます (つまり、一般的なコントロールは正常に動作しますが、それを使用して何か興味深いこと (たとえば、WPF) を実行することを忘れてしまう可能性があります)。UI は書くのが簡単なので、移植可能なものでロジックを作成すれば、いくつかのプラットフォーム固有の UI を組み合わせるのは簡単なことだと思います。

最初の質問については、どのような種類のパフォーマンスを得る必要があるかによって異なるため、意味があるかどうかを判断するのは非常に困難です。私個人としては、WinForms を使用して適切に設計された GUI では、GUI が原因でシステム全体の速度が低下するのを見たことがありません。そのため、なぜそれが問題を引き起こすのかわかりません。おそらく、GUI に関して作業が楽になるでしょう。。

2 番目の質問に関しては、ある時点で別のプラットフォームに移行する予定がある場合、Mono によって実装されているライブラリを確認したいと考えています (http://www.mono-project.com/Main_Page)、これは WinForms と GTK# をサポートしているため、クロスプラットフォームウィンドウに関するニーズのほとんどもカバーします。

いいえ、C/C++ で「高価なもの」を実行するのは意味がありません。C# と比較すると、潜在的な (そしておそらくわずかな) パフォーマンスの向上が生産性を上回ることは決してありません。それはひどい冗談です。本当に。それは近くにもありません。

これ (およびその中で参照されているすべての投稿) を読んでください。http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

の使用を検討してみるとよいかもしれません単核症. 。これは、Linux、Mac、Solaris、Windows などの多くのプラットフォームで動作する .NET のオープンソースバージョンです。

次に、高価なものを C/C++ でコーディングする方法について説明します。これは、間の違いを説明する非常に良い仕事をする記事です C/C++ および C# のパフォーマンス.

もう一度強調しておきますが、C++ のものは非常に高価です。上で述べたことを行うことに意味があるでしょうか?(.NET フォームは重労働な C++ を隠します)

前に述べたように、私は個人的に、VB.NET と C# の両方で書かれたアプリケーションの WinForms が原因でシステム全体の速度が低下していることに気づいていません。ただし、アプリケーションが本当にパフォーマンスを重視する場合、すべてを C# で記述すると、CIL にコンパイルされるため、わずかに速度が低下することに気づくかもしれません (http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/）。そのため、C# などの言語で GUI を作成すると、開発のその部分が少し簡単になる可能性があり、コードの重要な部分に取り組む時間を増やすことができます。ここでの唯一の注意点は、C# コードから C/C++ コードへの呼び出しが原因で速度が低下する可能性があることです。ただし、これは非常に可能性が低いと考えられます。

1) winforms で GUI を実行し、高価な作業をネイティブのアンマネージド C/C++ で実行するのは理にかなっていますか?

おそらくそうではありません。他の多くのネイティブ C DLL などと通信しない限り、C# は 5% ～ 5% 遅くなる可能性があります。 もっと早く C++ より (std::string を使用していると本当に役に立ちません)

2) 上記のシナリオに適した、優れたクロスプラットフォームウィンドウキットに関する推奨事項はありますか?

ボタンを備えた単純なフォームであれば、mono は変更せずに実行できる可能性があります。最近では、.NET WinForms のサポートがかなり充実しています。しかし、それは醜いです:-)

私は問題を誤解しているかもしれません, 、しかし、それがネットワーク監視システムである場合、なぜ「専用」Windows サービスとして書かれていないのでしょうか?

VB.NET は C# よりもそれほど遅いはずはありません。生成された IL コードに大きな違いがあるかどうかは 100% 確信はありませんが、私が思いつく唯一の利点 (および C# で書き直す正当な理由) は (C# の方が優れた構文とその他の利点があることを除けば) ）は、安全でないコードブロックを使用しているため、速度が少し向上する可能性があります。

C/C++ のものは最終的には良いアイデアになるかもしれませんが、現時点では YAGNI です。Linux のものと同じです。それを無視します、それは必要ないでしょう必要になるまで。そのままにしておいてください単純. 。あなたが言うように、単体テストは徹底的に行います。コードを動作させて、デザインを進化させるそこから。

私も少し前、組み込みハードウェアと (PCMCIA インターフェイス経由で) 対話する PC ベースの H/W テストツール (明らかに「UI オプション付き」という意味です) を開発する最良の方法を見つけようとしていたときに、同様のジレンマを抱えていました。

ボトルネックは、テスターが指定した意図した時間から最大 10 ミリ秒の偏差でテストを実行する必要があることでした。

例えば：テスターが次のテストシーケンスを作成するとします。

ステップ 2 で述べた遅延は 60ms を超えてはなりません。

バックエンドとして C++ WIN32 アプリケーションを選択し、UI 開発には VC++ 2005 Winform (.NET プラットフォーム) を選択しました。これら 2 つをインターフェースする方法の詳細については、以下を参照してください。 msdn
システムを次のように分離しました。
VC++ .NET の場合:

C++ WIN32 の場合:

完全なシステムが稼働しています。かなり安定しているようです。(上記のタイミングのずれがなければ)。
私たちが使用するテスト PC は H/W テストのみを目的としていることに注意してください (UI のみが実行されており、自動更新やウイルススキャンなどはありません)。等..）。

gtk-シャープは非常に優れたクロスプラットフォームツールキットです。

Gtk# は、mono および .Net 用のグラフィカルユーザーインターフェイスツールキットです。このプロジェクトは、gtk+ ツールキットとさまざまな GNOME ライブラリをバインドし、Mono および .Net 開発フレームワークを使用した完全にネイティブなグラフィカル Gnome アプリケーション開発を可能にします。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow