どちらのアプローチも、他のアプローチに比べて明確な利点はありません。一方のアプローチの方が常に優れていた場合、どこでもそれを使い始める可能性があります。
一般的に言えば、コンパイラには次の利点があります。
すべてのコードを事前に確認できるため、コードを生成するときに、各行を個別に解釈するよりもコードの最終バージョンを高速に実行できるように、多くの分析と最適化を実行できます。
コンパイラーは、テーブル内のメモリールックアップに関して、「動的ディスパッチ」や「継承」などの高レベルのアイデアと同等の機能を実行する低レベルのコードを生成することがよくあります。これは、結果として得られるプログラムが元のコードに関する情報を少なく覚える必要があることを意味し、生成されたプログラムのメモリ使用量を減らします。
- 通常、コンパイルされたコードはインタープリターコードよりも高速です。実行される命令は通常、プログラム自体とインタープリターからのオーバーヘッドではなく、プログラム自体のためのものだからです。
一般的に言えば、コンパイラには次の欠点があります。
- 動的型付けなどの一部の言語機能は、プログラムが実際に実行されるまでコンパイラーが何が起こるかを予測できないため、効率的にコンパイルすることが困難です。これは、コンパイラーが非常に優れたコードを生成しない可能性があることを意味します。
- コンパイラーは、実行するすべての分析を実行するコストのため、一般に「起動」時間が長くなります。つまり、コードを高速にロードすることが重要であるWebブラウザーのような設定では、コンパイラーは、何度も実行されない短いコードを最適化するため、速度が低下する可能性があります。
一般的に言えば、通訳には次の利点があります。
記述どおりにコードを読み取ることができ、コードを生成または最適化するために高価な操作を行う必要がないため、コンパイラよりも速く起動する傾向があります。
インタープリターは、プログラムの実行時にプログラムが何を行っているかを確認できるため、コンパイラーが認識できない可能性があるいくつかの動的最適化を使用できます。
一般的に言えば、通訳には次の欠点があります。
インタープリターは、実行時に使用可能なプログラムに関する情報をより多く保持する必要があるため、通常、コンパイラーよりもメモリー使用量が高くなります。
インタープリターは通常、インタープリターのコードの内側にCPU時間を費やします。これにより、実行中のプログラムの速度が低下する可能性があります。
インタープリターとコンパイラーには補完的な長所と短所があるため、言語ランタイムが両方の要素を組み合わせることがますます一般的になっています。 JavaのJVMはこの良い例です-Javaコード自体がコンパイルされ、最初に解釈されます。JVMは、何度も実行されるコードを見つけて、マシンコードに直接コンパイルできます。つまり、「ホット」コードはコンパイルのメリットを享受しますが、「コールド」コードはメリットを享受しません。JVMは、インラインキャッシュのような多くの動的最適化を実行して、コンパイラが通常提供しない方法でパフォーマンスをスピードアップすることもできます。
最新のJavaScript実装の多くは、同様のトリックを使用しています。ほとんどのJavaScriptコードは短く、あまり機能しないため、通常はインタープリターを使用して開始します。ただし、コードが繰り返し実行されていることが判明した場合、多くのJSエンジンがコードをコンパイルし、少なくともコードの一部をコンパイルし、標準的な手法を使用して最適化します。最終的な結果として、コードは起動時に高速です（Webページをすばやくロードするのに役立ちます）が、実行するほど高速になります。
最後にもう1つ、languagesはコンパイルまたは解釈されません。通常、Cコードはコンパイルされますが、実行中のコードのデバッグや視覚化を容易にするCインタープリターが利用可能です（これらは、しばしば導入プログラミングクラスで使用されます-少なくとも、以前は使用されていました）。一部のJSエンジンがコンパイルを開始するまで、インタプリタ言語と考えてください。一部のPython実装は純粋なインタープリターですが、Pythonコンパイラーはネイティブコードを生成します。現在、一部の言語はです。）他のコンパイラよりもコンパイルまたは解釈が簡単ですが、特定のプログラミング言語用のコンパイラまたはインタープリタを作成するのに何も妨げるものはありません。 Futamuraプロジェクション と呼ばれる理論的な結果があります。たとえば、解釈できるものはすべてコンパイルできることを示しています。