Javaコンパイル速度とScalaコンパイル速度

私はしばらくScalaでプログラミングをしていて、それが好きですが、プログラムのコンパイルにかかる時間に悩まされています。それは小さなことのように思えますが、Javaを使用すると、プログラムに小さな変更を加え、netbeansの実行ボタンをクリックすると、BOOMが実行され、時間の経過とともにscalaでのコンパイルに多くの時間がかかるようです。多くの大規模なプロジェクトでは、コンパイルに時間がかかり、Javaを使用していたときに発生する必要がなかったため、スクリプト言語が非常に重要になると聞きました。

しかし、私が理解しているように、私はJavaから来ています。Javaは他のどのコンパイル言語よりも高速であり、Scalaに切り替えた理由のために高速です（非常に単純な言語です）。

だから私は尋ねたかったのですが、Scalaをより高速にコンパイルできますか？scalacはjavacと同じくらい高速になりますか？

ScalaコンパイラーはJavaのものよりも洗練されており、型推論、暗黙の変換、およびはるかに強力な型システムを提供します。これらの機能は無料では提供されないので、Scalacがjavacほど高速であるとは思いません。これは、作業を行うプログラマと作業を行うコンパイラの間のトレードオフを反映しています。

とは言っても、コンパイル時間は既にScala 2.7からScala 2.8にかけて著しく改善されており、ダストが2.8に落ち着いた今でも改善は続くと思います。このページでは、Scalaコンパイラーのパフォーマンスを改善するための進行中の取り組みとアイデアのいくつかを説明します。

マーティン・オーダースキーは彼の答えではるかに詳細を提供します。

Scalaコンパイラーの速度（の欠如）には2つの側面があります。

1. 起動時のオーバーヘッドが大きい

   • Scalac自体は、ロードしてJitコンパイルする必要のある多くのクラスで構成されています。

   • Scalacはすべてのルートパッケージとファイルのクラスパスを検索する必要があります。クラスパスのサイズに応じて、これにはさらに1〜3秒かかる場合があります。

   全体として、ディスクキャッシュがいっぱいにならないように最初に実行する場合は、4〜8秒のスカラックの起動オーバーヘッドが予想されます。

   起動時のオーバーヘッドに対するScalaの答えは、fscを使用するか、sbtを使用して継続的にビルドすることです。IntelliJは、どちらかのオプションを使用するように構成する必要があります。そうしないと、小さなファイルでもオーバーヘッドが不当に大きくなります。

2. コンパイル速度が遅い。Scalacは、約500から最大1000行/秒を管理します。Javacはその約10倍を管理します。これにはいくつかの理由があります。

   • 型の推論は、特に暗黙の検索を伴う場合、コストがかかります。

   • Scalacは型チェックを2回行う必要があります。1回はScalaのルールに従い、2回目は消去後にJavaのルールに従います。

   • 型チェックの他に、ScalaからJavaに移行するための約15の変換ステップがあり、すべて時間がかかります。

   • Scalaは通常、特に機能的なイディオムが頻繁に使用される場合、Javaよりも特定のファイルサイズごとに多くのクラスを生成します。バイトコードの生成とクラスの書き込みには時間がかかります。

   一方、1000行のScalaプログラムは2〜3K行のJavaプログラムに対応する可能性があるため、1秒あたりの行数で数えた場合の速度の低下は、1行あたりのより多くの機能とバランスを取る必要があります。

   速度の改善に取り組んでいます（たとえば、クラスファイルを並列に生成するなど）が、この面で奇跡を期待することはできません。Scalacはjavacほど高速にはなりません。私は、ソリューションがfscのようなコンパイルサーバーと適切な依存関係分析を組み合わせることで、最小限のファイルセットのみを再コンパイルする必要があると考えています。私たちもそれに取り組んでいます。

Scalaのコンパイルには、Javaのコンパイルよりも少なくとも1桁長い時間がかかることに注意してください。この理由は次のとおりです。

1. 命名規則（ファイルXY.scalaファイルには、呼び出されたクラスが含まれている必要はなくXY、複数の最上位クラスが含まれている場合があります）。したがって、コンパイラは、特定のクラス/特性/オブジェクト識別子を見つけるために、より多くのソースファイルを検索する必要がある場合があります。
2. 暗黙-暗黙を多用すると、コンパイラーは、指定されたメソッドのスコープ内の暗黙の変換を検索し、それらをランク付けして「正しい」ものを見つける必要があります。（つまり、コンパイラーは、メソッドを検索するときに大幅に増加した検索ドメインを持っています。）
3. 型システム-Scalaの型システムはJavaのシステムよりもはるかに複雑であるため、より多くのCPU時間を必要とします。
4. 型推論-型推論は計算コストが高く、仕事をjavacまったくする必要がない
5. scalacには、GenICodeのコンパイルフェーズ中に魔法のキーの組み合わせCTRL-ALT-F12を使用して表示できる、完全武装した操作可能な戦闘ステーションの8ビットシミュレータが含まれています。

Scalaを実行する最良の方法は、IDEAとSBTを使用することです。エレメンタリーSBTプロジェクトをセットアップし（必要に応じて自動的に行います）、自動コンパイルモード（コマンド~compile）で実行します。プロジェクトを保存すると、SBTによって再コンパイルされます。

IDEAのSBTプラグインを使用して、SBTアクションを各実行構成にアタッチすることもできます。SBTプラグインは、IDEA内でインタラクティブなSBTコンソールも提供します。

どちらの方法（SBTが外部で実行されているか、SBTプラグイン）でも、SBTは実行されたままなので、プロジェクトの構築に使用されるすべてのクラスが「ウォームアップ」され、JITされ、起動時のオーバーヘッドがなくなります。さらに、SBTは、それを必要とするソースファイルのみをコンパイルします。これは、Scalaプログラムを構築するための最も効率的な方法です。

Scala-IDE（Eclipse）の最新のリビジョンは、インクリメンタルコンパイルの管理に優れています。

詳細については、「最高のScalaビルドシステムとは」を参照してください。

他のソリューションは、fsc-Scala 2言語用の高速オフラインコンパイラ -（このブログの投稿に示されているように）をIDEのビルダーとして統合することです。

ただし、Daniel Spiewakがコメントで言及しているように、直接 Eclipseではありません。

Eclipseが既に表面下でFSCを使用しているという理由だけで、Eclipse内で直接FSCを使用するべきではありません。
FSCは基本的に常駐コンパイラの上にある薄い層で、EclipseがScalaプロジェクトをコンパイルするために使用するメカニズムです。

最後に、ジャクソン・デイビスがコメントで私に思い出させるように：

sbt（Simple build Tool）には、完全ではありませんが、何らかの「インクリメンタル」コンパイル（トリガーされた実行による）も含まれています。また、次の0.9 sbtバージョンでは、拡張インクリメンタルコンパイルが機能しています。

fscを使用します。これは、バックグラウンドタスクとして動作し、常にロードする必要がない高速のscalaコンパイラです。以前のコンパイラインスタンスを再利用できます。

Netbeans scalaプラグインがfscをサポートしているかどうかはわかりませんが（ドキュメントにはそう記載されています）、それを機能させることができませんでした。プラグインのナイトリービルドを試してください。

Scala用に無料のJRebelプラグインを使用できます。したがって、「デバッガで開発」することができ、JRebelは変更されたクラスを常にその場で再ロードします。

Martin Odersky自身がどこかで暗示の検索（コンパイラーは、曖昧さを排除するために、同じ変換に複数の単一の暗黙が存在しないことを確認する必要があることを確認する必要があります）がコンパイラーをビジー状態に保つ可能性があると言っているどこかのステートメントを読みました。したがって、インプリシットを慎重に処理することをお勧めします。

100％Scalaである必要はなく、同様のものが必要な場合は、Kotlinを試してみてください。

-オリバー

私はこれが反対投票になると確信していますが、非常に迅速なターンアラウンドは、常に品質や生産性につながるとは限りません。

時間をかけてじっくり考え、実行する開発マイクロサイクルを減らします。優れたScalaコードは密度が高く、より重要です（つまり、付随する詳細や複雑さから解放されます）。それはより多くの思考を要求し、それには（少なくとも最初は）時間がかかります。個々に少し長いコード/テスト/デバッグサイクルを減らしても生産性と作業の品質を向上させることができます。

つまり、Scalaにより適した最適な作業パターンを探します。