Scala CLIはScalaの便利コマンドラインツールで、スクリプト実行やREPL、パッケージングなどをやってくれる。今回はスクリプティングの話。
Scala CLIはビルドサーバを起動する
Scalaはコンパイル型の言語であり、JVMでコンパイラが動作するという特性上、毎回最初からコンパイルを行うとパフォーマンス上のオーバーヘッドが生じる。必要な処理が最初から走るし、JITが動いていないし、最適化もかかっていないからだ。
このため、Scala関連のツールキットは、起動時に自動的にビルドサーバを起動し、以降はBuild Server Protocolというのを使ってそのサーバと交信してコンパイルやその結果を受け取る、という挙動をすることが多い。
% cat code.scala.sc //> using scala 3.5.2 println("hello, scala cli!") % scala-cli code.scala.sc Compiling project (Scala 3.5.2, JVM (17)) Compiled project (Scala 3.5.2, JVM (17)) hello, scala cli! % jps 712651 BloopServer 1083639 Jps
これにより、二度目以降のコンパイルと実行はパフォーマンスが向上し、開発者体験が良くなる、という仕掛けになっている。
ビルドサーバのリソース
しかし、開発をしているならともかく、仕上がったものをただ実行したいだけ、という場合にはこの機能は無駄だ。ビルドサーバなので数百MiBオーダーくらいのメモリを食うし、特に何もしないだけでこれが常駐するのは困る。
ビルドサーバが起動しないようにする
もちろんこの問題はScala CLI側でも認識されていて、特定の場所にオプションを指定することでビルドサーバが起動しないようにできる。代わりにコンパイルパフォーマンスが犠牲になるので、開発が終わってあとは実行するだけ、というときに使うと良さそう。
コマンドラインオプションを指定する
最も素朴には、scala-cliに--server=falseをつけることでビルドサーバの起動を抑止できる。
% scala-cli --server=false code.scala.sc
スクリプト中で指定する
もしくは、スクリプト自体にshebangを添加させるという方法も使える:
#!/usr/bin/env -S scala-cli --server=false //> using scala 3.5.2 println("hello, scala cli!")
% chmod u+x code.scala.sc
% ./code.scala.sc
