JavaScriptコードはコンパイルされておらず、JITもコンパイルされていないと言ってもいいですか？もしそうなら、それはコメントがパフォーマンスに影響を与えることを意味します、そして私は私のコメントを置く場所に非常に注意する必要がありますか？可能な場合は関数定義の上下に関数コメントを配置し、パフォーマンスを最大化したい場合はループ内にコメントを配置しないようにしますか？ほとんどの場合（少なくとも非ループの場合）、パフォーマンスの変化はごくわずかであることを私は知っていますが、これは、特にフロントエンド/ js開発者にとって、知っておくとよいことだと思います。また、私が最近行ったjs評価についても関連する質問がありました。
質問する
6764 次
5 に答える
29
JavaScript コードはコンパイルされておらず、JIT でさえもコンパイルされていないと言うのは正しいですか?
いいえ。JavaScript は伝統的に「インタープリター型」言語ですが (必ずしもそうである必要はありません)、ほとんどの JavaScript エンジンは必要に応じてオンザフライでコンパイルします。V8 (Chrome および NodeJS のエンジン) は、すぐにすばやくコンパイルしてから、頻繁に使用されたコード (古い FullCodegen+TurboFan スタック) に戻って積極的に最適化していました。少し前に実世界で多くの測定を行った後、彼らは最初に解析して byteocde に変換し、コードが再利用される場合はコンパイルすることに切り替え (新しい Ignition+TurboFan スタック)、実行をコンパイルしないことでメモリを大幅に節約しました。 -ワンスセットアップコード。あまり攻撃的でないエンジンでも、少なくともテキストを何らかの形式のバイトコードに解析し、コメントを早期に破棄します。
「解釈された」対「コンパイルされた」は、通常、言語の問題よりも環境の問題であることに注意してください。C インタープリターがあり、JavaScript コンパイラーがあります。言語は環境と密接に関連している傾向があります (1995 年にさかのぼって、常にそれよりも広く使用されていたにもかかわらず、JavaScript が Web ブラウザー環境と関連する傾向があるように)、それでも (これまで見てきたように)、変動があります。
もしそうなら、それはコメントがパフォーマンスに影響を与えるということですか...
初期の解析段階では、非常に、非常に、非常に最小限のものです。しかし、コメントは過去をスキャンするのは非常に簡単で、心配する必要はありません。
ただし、本当に心配なjsmin場合は、Closure Compilerなどのツールを使用してスクリプトを縮小できます(単純な最適化だけでも)。前者は、コメントや不要な空白などを取り除くだけです (それでもかなり効果的です)。後者はそれを行い、実際にコードを理解し、インライン化などを行います。したがって、自由にコメントを付けてから、これらのツールを使用して、スクリプトが最初に読み込まれたときにそれらのコメントが与える可能性のあるわずかな影響が、縮小ツールを使用してバイパスされるようにします。
もちろん、JavaScript のパフォーマンスに関しては、エンジンが大きく異なるため、クロスエンジンを確実に予測することは困難です。したがって、実験は楽しいものになります。
結果？私の見解では、テストの測定誤差内に識別可能な違いはありません。
于 2012-04-19T16:56:59.490 に答える
10
コメントがもたらす最大の影響は、ファイル サイズが肥大化し、スクリプトのダウンロードが遅くなることです。したがって、すべてのプロのサイトが生産的なバージョンに最小化ツールを使用して、js を可能な限り小さくする理由です。
于 2012-04-19T16:59:50.597 に答える
4
多少の効果はあるかもしれません。ただし、非常に最小限の効果です（IE6でさえコメントを正しく処理します！確認する必要があります...）。
ただし、ほとんどの人は、コメントを削除するミニファイアを使用しています。それで大丈夫です。
また：
V8 は、JavaScript を実行する前にネイティブ マシン コードにコンパイルすることにより、パフォーマンスを向上させます。
于 2012-04-19T16:58:28.480 に答える
0
関数が inlined になるのを防ぐことができますが、これはパフォーマンスに影響しますが、これは実際には起こるべきではありません。
于 2019-03-29T03:21:03.740 に答える