一部で話題の 長文コメント のあたりで触れられてる「 Javaの理論と実践: パフォーマンスに関する都市伝説を再検証する 」の記事。以前ブックマークしたまますっかり忘れてたので、いい機会なので読んでみました。
字義通りに受け取りすぎてしまう人いるみたいですけど、結論から言えば、速いケースは十分あるでしょうね。
記事ではメモリアロケーション処理について論じていますが、「malloc()でヒープメモリ確保」と「（最適化された結果）レジスタやスタックに割付け」を比較すれば、後者のほうが速いのは当然です。こういった差を積み重ねられれば、Cなどでべた書きするよりも、JavaなどのVM系環境の方が速くなる……というのが、動的最適化による高速化の思想でしょうか。
もちろん、最適化ゲインが動的最適化のための統計・分析コストを上回る範囲内にあることが前提です。逆に言えば、全コスト内で占める動的処理コストの割合が、ソフトウェアの巨大化と計算機パワーの増大によって相対的に低下したことで可能になった高速化手法であるとも言えるでしょう（機能ではなく、高速化のための動的化ってのは今まで考えたことなかったな……）。
もちろん、目的に比べて過剰な動的処理を行えば、当然最適化ゲインを食いつぶすだけで高速化にはなりませんし、とりうる挙動が限定されるシチュエーションでは、一般的・汎用的シチュエーション向けにチューニングされた最適化よりも、そのシチュエーションに特化した手作業の静的なコードの方がより効率的に動作するでしょう（静的処理の最後の砦？）。
初期のJavaなどは後者の悪い部分が目立っていたわけですが、計算機パワーの増大と最適化手法の進歩の相乗効果で、最近では前者に転んできたといったところでしょうか。
一方、現在でも後者のシチュエーションを積極的に利用してるのが、いわゆる「組み込み系」ですね。シチュエーションを限定すれば、現在の半導体技術の成果でより小型に、より広範囲にコンピューティングを提供することができるという「
イノベーション
」の一典型です。
この分野でも、ICチップと無線の融合という形で次のイノベーションが登場しつつありますけど。