05 どっちのコンパイルを使えばいいんだろぅ
日付を管理していなかったので、正確な記述日時がわかりません。
ので、サイト「猿頁」開設日としました。御了承ください。
以上、BASICの発展過程と併せて2種類のコンパイル形式が存在するいきさつをお話してきました。
で、つまるところ、
って話になると思ぅんですが。
世間様一般には、「ネイティブコードコンパイルのほうがいいぞぅ」といぅことになっていますが、私としては
と思っています。
まーたそんなヘソ曲がりなことを言い出したよおまえさんは、って古典落語みたいなツッ込みを入れる前に、まぁちょいと聞いておくんなさいよ。
ネイティブ EXE は、p-codeEXE よりも動作が速いといぅことになっています。けど。実はこの「動作が速い」ってのは、限りなく絵に描いた餅に近いホントです。
確かネイティブコードコンパイル機能を搭載した VB5.0 の発表当時、Microsoft は「p-codeEXE と比較して最高で 8 倍、平均 3 倍の動作速度を実現」(だったかな)って言っていたはずです。
けど、この「平均 3 倍」ってのは意味がないですね。どこのどんなプログラムを集めてきて平均したのか知りませんけど、VB を使っている個々の開発者にとって唯一の関心事は「オレが今作っているプログラムはどのくらい速くなるんだ？」ってことでしかないんですから。平均値ではなくてね。
で、VB のネイティブ EXE が自分の中でマシン語として動作を実現しているのは、演算子だけを使った計算と一部 API 関数のみです。関数を使った演算や、VB の仕様の中でソフィスティケートされた API 機能については、ランタイム内のサブルーチンをコールします。ランタイム内サブルーチンの動作速度は、p-codeEXE からコールされてもネイティブ EXE からコールされても変わるわけはないんですから、この部分についての動作速度は同じですね。
また、標準添付されている ActiveX コントロールや、サードパーティから提供されている別売りのコントロールに関わる動作速度も p-codeEXE と変わりません。この場合のボトルネック(動作速度が遅くなる一番の原因)はコントロール側、及びコントロールとの I/O にあるので、自作プログラム側だけがいくらマシン語になったってスピードは変わりません。ねぇ。
しかし、VB 製プログラムの用途のかなりの部分をフロントエンドまたはスタンドアローン、つまり使用者が直製キーボードやマウスで操作するのが主目的のプログラムが占めています。で、そーいぅプログラムはネイティブコンパイルしたってさほど速くなりません。
逆にネイティブEXEの短所としては、
- プログラムサイズがでかいために配布がしにくくなる
- コンパイルにもぅれつに時間がかかる
- VBの開発環境(IDE)での実行と動作が異なる
本来ネイティブ EXE での配布を前提にするなら、動作テスト・デバッグ作業もネイティブ EXE で行わなきゃいけません。IDE でインタプリタ実行しながらのテストで完動したからって、それがネイティブ EXE での動作保証の根拠にはなりませんもん。
でも、これって修正をかけるたびにネイティブコードコンパイルをかけ直さなきゃなりませんし、IDE 環境でのデバッグもできません。本来、ネイティブ EXE にするんなら、デバッグは Visual Studio などのシンボリックデバッガ環境とかで行うのがスジなんですもん。
デバッグ作業は効率よく IDE 内で実行しながら行い、ちょっとでも速くなることを期待してネイティブコードコンパイル。で、配布開始したり客先に納品したりしてから「ちゃんと動かない」ってクレームをいただいて「な、なぜなんでしょぅねぇ」などと情けなげな返答をしたりして。あぁいやだ。
ので、さほど動作速度が変わらないタイプのプログラムなんであれば、p-codeEXE をものすごくおすすめします。ベンチマークとかで厳密に測定しなくても、体感的に差違が感じられないのであればネイティブEXEにするメリットはまったくありませんよ。
絶対にネイティブEXEをおすすめしちゃうのは、VC++ などとのマルチランゲージでシステム開発するとき。VC++ で DLL 作って VB から Call するよぅなパターンですね。こんな時はシンボリックデバッガで VC++ も VB もまとめてデバッグしたいわけですから。VB 製プログラムをネイティブ EXE にしといて、VC++←→VB 間をシームレスにソース追っかけていけるといぅ、涙が出るくらいありがたい環境になりました。