Replies: 3 comments 7 replies
-
|
Hello @Flowdalic , Running script in Scala CLI consists of multiple steps:
Any/all of those steps may be slower.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your much appreciated feedback. I should have mentioned in my initial post that all execution times are from a second run, assuming that the two script runners, scala-cli and Ammonite, both use cached class files. This hopefully eludes the code compilation process. Is this assumption correct? In any case, here are the timings for "scala-cli version" (I assume you meant that with "scala-cli about") and "amm-3.2 --version". Note that amm-3.2 is Ammonite with Scala 3.2. Unlike scala-cli, Ammonite seems to bundle a specific Scala version in its binary. flo@raspi:~$ time scala-cli version
Scala CLI version: 0.1.21-SNAPSHOT
Scala version (default): 3.2.2
real 5m55.893s
user 5m35.924s
sys 0m5.373s
flo@raspi:~$ time amm-3.2 --version
Ammonite REPL & Script-Runner, 2.5.8
real 0m30.116s
user 0m21.833s
sys 0m1.406sFor for you second question, the following shows the execution time of "scala-cli compile". Note that I believe that a bloop server was already started. flo@raspi:~$ time scala-cli compile get-number-of-gentoo-devs.sc
real 11m52.481s
user 10m8.755s
sys 0m15.729sThen I've added a few println(Instant.now) into the script (updated scripts at the end of the post). Here is the output and the timinings. Note that I now also use amm-3.2, so Ammonite with Scala 3.2 (was previously Scala 3.1): In both cases, the script rougly runs for one minute, where the HTTPS request is the biggest contributor to the scripts runtime. But in scala-cli's case, the total execution time is 28m while with Ammonite is 1m. It certainly isn't ideal nor desirable that Ammonite internal-logic doubles the execution time of the script. But compared to scala-cli, Ammonite performs far better. I believe your last point became obsolete, since Ammonite can use Scala 3.2 and I've now provided a comparison where both, scala-cli and Ammonite, use Scala 3.2. As we see, network requests are quite expensive on such a low-end system (1min for an HTTPS request). I wonder if scala-cli does a lot of them on every invocation and, if so, if this number could be reduced, and if this could be one contributor to extended runtimes we are seeing. In any case, I would appreciate if someone could provide some architectural analysis of scala-cli and/or Ammonite, discussing their differences, and maybe provide some pointers where Ammonite potentially gets its speed advantage from. Thanks The common part of the two scripts, one for scala-cli and one for Ammonite, now looks like this: import java.time.Instant
import org.jsoup.Jsoup
println(Instant.now)
val session = Jsoup.newSession.timeout(10 * 60 * 1000)
println(Instant.now)
val doc = session.url("https://www.gentoo.org/inside-gentoo/developers/").get
println(Instant.now)
println(doc.title)
println(Instant.now)
val table = doc.getElementsByTag("table")
// Currently the site only contains exaclty one table
.first
println(Instant.now)
val numTableRows = table.child(0).childrenSize
println(Instant.now)
println(s"Currently ${numTableRows} rows") |
Beta Was this translation helpful? Give feedback.
-
|
As there is huge latency on your system when network requests are involved, it could be, that scala-cli is doing some more up-to-date checks over the network with each start. This is just some suspicion though; but if this suspicion turn out to be true, it might be a good idea to avoid constant up-to-date checks for a reasonable time interval. |
Beta Was this translation helpful? Give feedback.
-
|
Btw. ▶ time scala-cli version --offline
Scala CLI version: 0.1.20
Scala version (default): 3.2.2
scala-cli version --offline 0.01s user 0.02s system 21% cpu 0.142 total
▶ time scala-cli version
Scala CLI version: 0.1.20
Scala version (default): 3.2.2
scala-cli version 0.05s user 0.02s system 6% cpu 1.147 total
▶ time amm --version
Ammonite REPL & Script-Runner, 2.5.8
amm --version 0.28s user 0.05s system 46% cpu 0.709 total |
Beta Was this translation helpful? Give feedback.
-
|
I can't reproduce that slowdown locally. After an initial run for both Scala CLI: Ammonite: (first one is not the initial run, and seems to be an outlier here) Scala CLI actually seems to be slightly faster here (and consistently so for me locally). |
Beta Was this translation helpful? Give feedback.
-
|
Scala CLI also uses less CPU time overall (in my runs above, ~2.3s vs ~3.5s) Edit: that said, this doesn't account for the Bloop server CPU time for Scala CLI. Don't know if it accounts for the CPU time of the JVM that Scala CLI starts to run the user code either. But the overall time ("total" one in the |
Beta Was this translation helpful? Give feedback.
-
|
It's expected that Scala CLI does more work than Ammonite upon first run, as it needs to download Scala JARs, Bloop JARs, it needs to start Bloop, … |
Beta Was this translation helpful? Give feedback.
-
|
I wouldn't expect that you are able to reproduce this "locally", which presumably means on your desktop or laptop system. You need a low-end machine to recreate the environment I used. |
Beta Was this translation helpful? Give feedback.
-
I think scala-cli is great. The using directives take scala scripting to the next level. I am also a long time Ammonite user, which took REPLs for the JVM to the next level. So please don't take the following as bashing either of those.
I started a wild and crazy attempt to run Scala scripts on a low-end ARM (little-endian, armle) machine. Debian provides JDK 17 builds for this architecture, using the Zero VM.
Comparing the run times between scala-cli and Ammonite to execute a simple script shows that scala-cli is approximately 6x slower than Ammonite. The script simply performs a HTTP lookup and counts the number of rows in a table (using jsoup). The sources of the two scripts, one for Ammonite and one for scala-cli, are at the end of the post.
I am curious about the sources of the slowdown. I wonder if it is related to scala-cli using bloop? But maybe Ammonite does the same? I am not familiar with the internals and architecture of both projects.
In any case, it would be great to learn more about it. Maybe the situation can be improved (on both projects). It would be really great to be able to execute Scala scripts on low-end machines too. Even though, I would expect that it is not a high priority. I want to find out how far the JVM ecosystem can go when it comes to scripting for low-end machines and how competitive it would be to e.g., Python. Then, we may shift the boundaries for Scala scripting on low-end machines. Maybe make Scala more attractive for the uncountable low-end machines out there, pushing the whole Scala ecosystem.
scala-cli script:
Ammonite script:
Beta Was this translation helpful? Give feedback.
All reactions