3

2 つの質問:

  1. .NET のパフォーマンスと VB 6 のパフォーマンスを比較した偏りのないデータを教えてもらえますか? 調べてみましたが、意外と見つけにくいです。
  2. アプリが顧客のサイトで動作するとき、.NET のパフォーマンスと VB 6 のパフォーマンスを比較する最良の方法は何ですか?

WindowsForms クライアント サーバー アプリ (2.0 用に作成され、まもなく 3.5 SP 1 にアップグレードされます) があり、以前の VB 6 バージョンと比較して「パフォーマンスが遅い」という顧客からの不満があります。「パフォーマンスが遅い」という言葉は非常に曖昧で一般的であることは承知していますが、.NET は VM で実行されるため、.NET コードが VB 6 コードよりも遅いと仮定するのは本当ですか? 私はコードの 100% を C# で書いたので、第三者やウィザードによって移植されたわけではありません。

すべての顧客がこの苦情を申し立てるわけではないため、環境上の問題が疑われます。顧客サイトでパフォーマンスを測定する唯一のオプションですか? 一部のお客様は、Novell ネットワーク上の Windows Server 2003 で SQL Server 2005 を使用しています。Windows ネットワーク上の同様のマシンとは劇的に異なるデータ アクセス パフォーマンスが見られるでしょうか?

4

8 に答える 8

4

パフォーマンスは、ほとんどの場合、何をしているかに依存します。

可能であれば、現場に行き、顧客がアプリを使用している様子を観察します。スローダウンが発生している場所を見つけて、それをプロファイリングします-理想的には同様の量のデータなどを使用して.

お客様のサイトでクライアントとサーバーの両方のパフォーマンスを確認し、どちらが実際に問題を引き起こしているかを調べます。ネットワークの構成と健全性を確認してください - ばかげた設定では、動作は維持されますが、非常に遅くなることがあります。

于 2008-10-24T19:42:57.903 に答える
4

最初に言及する必要があるのは、.Net コードはVM では実行されないということです。確かに .Net プログラムは Java の ByteCode に似た IL にコンパイルされますが、重要な違いは、VM によって解釈されるのではなく、アプリの起動前に IL も完全にネイティブ コードにコンパイルされることです。

.Net/VB6 の比較に移ります。特定のデータを指摘することはできませんが、個人的な経験からすると、あなたが何をしているかによって異なります.

これを説明するために、それぞれ vb6 と .Net バージョンを持つ 6 つの異なるベンチマーク アプリケーションについて考えてみましょう。各アプリケーションは特定の操作を選択し、それを 100,000 回実行してから、かかった時間を記録します。これは思考実験であることに注意してください。実際のアプリの結果を実際に見たことはありません。しかし、両方のプラットフォームの長所と短所を感じています。

  • アプリケーション A は、深刻な CPU 負荷の高い数値処理を行います。この場合、ここでの結果はほぼ同じであると信じなければなりません。VB6 と .Net はどちらもネイティブ コードにコンパイルされるため、CPUmult命令は関係なく同じです。とはいえ、使用していない場合はOption Strict、どちらのプラットフォームでもすぐに問題が発生する可能性があります. C# (基本的には常にOption Strict) を使用したため、.Net コードに利点が生じる可能性があります。

  • アプリケーション B が出て、データベースから値を取得します。繰り返しますが、結果はおそらく非常に近いですが、2 つの理由から .Net に非常にわずかな優位性を与える必要があります。ネイティブ SQL クライアントを使用しているため、おそらく少し高速であり、自動接続プーリングなどを実行して、繰り返し接続するよりも、一度接続してその接続を再利用するなどを簡単に除外できます。しかし、コードに関する限り、リンゴとリンゴを比較すると、この 2 つは非常に近いものになる可能性があります。

  • アプリケーション C は、フォームの表示と非表示を繰り返します。ここで、vb6 に同意する必要があります。これは、率直に言ってレンダリングコストが安くなる、古くて派手さの少ないウィジェット セットに基づいています。また、WinForms コンポーネントはそれほど高速であるとは言えません。ただし、違いはおそらくあなたが思っているほど大きくはなく、フォームを完全に再描画することもあまりないでしょう。これはおそらく、ユーザーが不満を言う速度の遅さです。

  • アプリケーション D は文字列操作に基づいており、ここで .Net に同意する必要があります。VB6 と .Net はどちらも文字列操作が遅いことで知られています。ただし、.Net には、vb6 では利用できない多くのツールが用意されており、開発者がこの遅さを克服するのに役立ちます。とはいえ、これらのツールを認識していない場合、文字列操作の選択を誤ると、アプリが役に立たない作業を行って簡単に行き詰まる可能性があります。これは、ユーザーの苦情にも寄与している可能性があります。

  • アプリケーション E は、Xml ドキュメントをメモリに繰り返しロードしようとしています。繰り返しますが、.Net には利点があると考えざるを得ません。まず、vb で使用できる xml ツールはせいぜい原始的でした。それらが大幅に改善されていない可能性は低いと思います。さらに、.Net のガベージ コレクターは非常にスマートで、ロード中にメモリを割り当てたり解放したりする利点があります。ただし、ここでの最大の問題はディスク速度になると思います。つまり、違いはそれほど大きくないということです。

  • アプリケーション F は、繰り返し .Net または vb6 プログラムを開始し、(「準備完了」の何らかの定義のために) 準備が整うのを待ってから閉じます。ここでは、2 つの理由から、vb6 が有利である可能性があります。まず、.Net は最初の実行時に IL をバイトコードにコンパイルする必要があります。ありがたいことに、それは最初の実行にすぎません。次に、.Net アプリは、参照されているアセンブリも読み込む必要があります。比較すると、VB6 ランタイムははるかに小さいです。ただし、これは通常、特定のマシンでアプリを初めて起動したときにのみ当てはまり、.Net コードをプリコンパイルする方法があります。これは、知覚される速度低下にも寄与する可能性があります。

重要な点の 1 つは、これらすべてのアプリケーションで、.Net アプリのメモリ フットプリントがはるかに大きくなる可能性が高いということです。いくつかの理由で、開発者はこれをパフォーマンスの悪い特性と考える傾向がありますが、実際にはその逆です。アプリがより多くのメモリを使用している場合は、おそらくディスクへのアクセスに費やす時間が少なく、ディスクははるかに低速です。おそらくキャッシュも増えているため、CPU時間を節約できます。特に.Netの場合、より重要な期間、またはPCがアイドル状態の場合に、割り当て/割り当て解除操作を節約しています。

時間はありませんが、誰かが今日のコーディング ホラーで言及されている StopWatch 実装 (少なくとも .Net 側) を使用して、これらのそれぞれの実際のベンチマークを取得するのを見るのは興味深いことです。

于 2008-10-24T20:04:45.707 に答える
2

おお、見やすい。WF と VB6 の両方で 50 個のボタンをフォームにコピー アンド ペーストし、それらのペイント速度を並べて比較します。.NET が遅いのではなく、WF が遅いのです。私はそれを本当に突き止めたことはありませんが、要因は次のとおりです。

  • Button クラスの描画は非常に遅いです。コンテナが持っていない透明度のために背景をペイントするようにコンテナに要求します。
  • VB6 には、Label などのウィンドウレス コントロールがいくつかあります。WF では、すべてのコントロールがウィンドウです。
  • Visual Styles は無料ではありません。
  • 彼らは VB1 が 386SUX でうまく動作するように一生懸命働きました。
于 2008-10-25T04:59:36.173 に答える
2

  1. この種のデータを探したことはありません。ベンチマークの目的でよく使用される正規の「ペット ショップ」アプリを見ることができます。おそらく、開発プラットフォームの両方のフレーバーで利用できます。＃2は答えるのがはるかに重要だと思います。ペット ショップがすぐに実行されるかどうかは誰が気にしますか。重要なのは顧客のアプリです。

  2. ほとんどのパフォーマンスの問題は、データベースやネットワークに関連しています。バージョン間でデータベースに大幅な変更を加えた場合は、最初に SQL トレース/プロファイリング ツールを使用してプロファイリングするか、いわゆる「低速パフォーマンス」フォームをサポートするために実行される主要な procs/sql で簡単なテストを実行します。

私があなたを正しく理解していれば、一部のクライアントでは問題ないように見えますが、他のクライアントではそうではないようです..NETであり、VB6は問題なかったという事実について誰かがあなたを叩いています。どうもありがとう. クライアント間のネットワークの違いは、間違いなく重要な違いです。サーバー OS、スイッチの速度、ネットワーク インフラストラクチャなど、調査すべき変数が非常に多くあります。しかし、.NET と VB6 とは何の関係もないことは間違いありません。

于 2008-10-24T19:52:25.203 に答える
2

私は、質問に答えるのではなく質問する人のように聞こえるリスクを冒していることを知っていますが、私がこれを完全に役に立ちたいという精神で提供していることを理解しています.

.net アプリが VB6 よりも遅いと顧客が不満を言っているというあなたのより大きな懸念の文脈では、VB6 が実際に速いことがわかった場合、ダウンコンバートを真剣に検討していますか? そうでない場合、なぜテストで時間を無駄にするのでしょうか?

顧客が間違っていて、.net の方が高速であることを決定的に証明できたとしても、顧客の苦情を却下しても、実際には何も得られません。原因を議論するのではなく、問題を解決することに時間を費やしてください。最終的には、誰もがより幸せになります。

最後に、より良いパフォーマンスを得るためにプラットフォームを切り替えることは、一般的に生産的な努力ではなく、通常、プラットフォーム戦争が常識に勝つようにするプログラマーによる最後の溝の努力であることに注意してください. 私の提案は、既にビルドされているプロジェクトの .NET/VB6 パフォーマンス比較を無視し、アプリケーションの特定の関心領域を見つけることに時間を費やし、できる限り最適化することです。

于 2008-10-24T20:16:01.083 に答える
1

.Net ファンには千の言い訳があります。ある時点で Microsoft は比較を禁止していましたが、これにはおそらく理由があります。

.Net が遅い理由の 1 つは、実行時の起動コストです。その一部は、JIT コンパイルに必要な時間です。その一部はガベージコレクションです。その一部は、大量のメモリが消費されることによるオーバーヘッドであり、より多くのスワッピングが発生する可能性があります。その一部は、インライン コード (つまり、OS 呼び出し、多くの標準ライブラリ) の外側で、COM や Win32 レイヤーを介したサンク処理が必要になることです。

ただし、大量のメモリと複数の高速 CPU とハード ドライブの速度を備えた新しいマシンでは、これらの一部が隠されています。マスキングをしてもムダが減るわけではありません。

.Net は、Java が得意とするのと同じことを対象としていました。高速に記述された使い捨てコードと、長期間ロードされて実行されたままになるサーバー側のもの。

于 2009-03-31T01:13:22.597 に答える
1

実質的に VB 6.0 と VB.NET で記述された同じクライアント アプリケーションについて話している場合は、VB 6.0 アプリの方が最初の画面にすばやく到達する可能性が高くなります (.NET JIT コンパイルとアセンブリの読み込みのため)。その後、パフォーマンスはほぼ同じになるはずです。

問題は、実際の状況では、アプリケーションのアーキテクチャが異なり、真のパフォーマンス比較が意味をなさないことです。

于 2008-10-24T19:56:20.250 に答える
-1

VB6 アプリと比較した場合のパフォーマンスは、おそらく C# と VB6 の比較よりも、アプリケーションの設計によるものです。適切に設計されていれば、C# アプリの 9.5/10 倍高速になると推測できます。.Net は VM 内では実行されません。CLR JIT は .Net アプリをマシン レベルのコードにコンパイルするため、非常に高速です。管理されていないコードよりも実行が少し遅い理由は、実行されるサンドボックス .Net が管理されており、オーバーヘッドがあるためです。

于 2008-10-24T19:46:37.820 に答える