VSTOアドインとVBAのパフォーマンス

Question

機能的に同一のプログラムを作成する場合は、2つのパフォーマンスの比較が不思議です。私はVBAで必要としている比較関数の量があれば、アドインがより適切かもしれないと考えるようになっているプロジェクトに取り組んでいます。

Answer 1

これらのプログラムが何をしているか、どのように行っているかによって異なります。

VSTO /.netはVBAより高速で、複数のスレッドで実行されるコードを書くことができます。しかしExcelはCOMであり、最終的にはすべてがSTA（シングルスレッドアパートメント）パイプラインに入る必要があり、マネージ（.net）コードはCOM Interopを介してCOMと通信します。つまりプライマリ相互運用アセンブリは「ネイティブ」VBAよりも低速です。言い換えれば

：

• あなたのプログラムは、多くの処理を行い、非常に少数のスプレッドシートは/は、VSTOを行く読み書きします。
• あなたのプログラムは、スプレッドシートのやりとりを多く行い、VBAになります。スプレッドシートのやりとりは、VBAができる最も遅いものですが、VSTOで行うことは、マネージコードからCOMまでマーシャリングする必要があるため、さらに苦労します。

VBAのユーザー定義関数を公開し、VBAコード呼び出しをExcelの相互運用機能アセンブリを使用せずに実際のコンピューティングを実行する参照可能なCOM可視の.net DLLにすることができます。

よく書かれたVBAコードは、同等のVSTOコードよりも優れている可能性があります。

私は、VBAで必要としている比較関数の量が多いほど、アドインが適切かもしれないと考え始めています。

VBAにもExcelアドインを書き込むことができます。関連する技術が少ないほど、お互いに話す必要が少なくなります。 - ソリューションは、最高の実行

• パフォーマンス：一日の終わりに、それはあなたの要件、環境や経験に応じて異なる適用される場合がありますが、物事の数に与えるどのくらいの重要性とのバランスが、ですか？
• 保守性 - どのソリューションを維持するのが最も簡単ですか？
• 配備 - どのソリューションが最も簡単に更新および展開できますか？
• ソースコントロールからチーム欲求不満 Foundation ServerのとのGitへのVisual Studioフック。 VBEはRubberduck（私の小さなペットプロジェクト）でGitをやることができますが、最新バージョンはまだベータ版であり、少し不安定です（C＃を知っていればオープンソースなので、安定化することができます）。
• ユニットテスト - Visual Studioでは単体テストの書き込みと実行が簡単です。 VBEはRubberduckでも同じことができますが、VBEアドインがなければ、アドホックテストに頼るか、VBIDE APIへのプログラムによるアクセスを有効にし、VBAベースの単体テストフレームワークを使用する必要があります。