| 24 Jan 2023 |
 velvetbaldmime#6377 | $ hyperfine "scala-cli run --native test.scala"
Benchmark 1: scala-cli run --native test.scala
Time (mean ± σ): 347.6 ms ± 9.3 ms [User: 29.6 ms, System: 20.7 ms]
Range (min … max): 332.3 ms … 363.4 ms 10 runs
$ hyperfine "scala-cli compile --native test.scala"
Benchmark 1: scala-cli compile --native test.scala
Time (mean ± σ): 296.8 ms ± 3.7 ms [User: 131.5 ms, System: 94.8 ms]
Range (min … max): 290.7 ms … 303.9 ms 10 runs
same story | 10:02:06 |
| velvetbaldmime#6377 | ged would you expect this? | 10:02:11 |
 ragnar#4252 | Which is why my initial comment said that its useless to try and have scala-cli compile in the shebang line, because it still does all of the scala-cli initialization and checking and stuff, which is the expensive part. | 10:02:22 |
| ragnar#4252 | Also, while we are at it running --server=false is slower than starting bloop. | 10:04:07 |
| ragnar#4252 | * Also, while we are at it running --server=false is can be slower than starting bloop. | 10:04:31 |
| velvetbaldmime#6377 | it seems to do _a lot_for each run - if you do -v -v on compile it
1. Checks the dependency jar caches
2. re-invokes Bloop compile
3. moves semanticdb files around? | 10:06:02 |
| ragnar#4252 | Which is to say, scala-cli is wonderful for what it does, but it is not meant for use cases where you have a rarely changing script that you want to execute often :-) | 10:06:31 |
| velvetbaldmime#6377 | IMO I think all of those things can be addressed with more caching, they don't seem to be strictly necessary | 10:06:55 |
| velvetbaldmime#6377 | 
Download image.png | 10:08:32 |
| velvetbaldmime#6377 | It does a lot | 10:08:33 |
| ragnar#4252 | Question is, if optimizing “rarely changing files” is an important usecase of scala-cli 🤷 | 10:08:45 |
| ragnar#4252 | package --native has become quite the viable option … except for some JDK methods I am missing 😄 | 10:09:30 |
| velvetbaldmime#6377 | FWIW I also
1. Develop with scli run -w . using JVM
2. Package with -native before running it hundreds of times | 10:10:32 |
| velvetbaldmime#6377 | And when I'm missing a JDK method.. well, C libraries make an appearance and then nothing works | 10:11:48 |
| ragnar#4252 | My opinion is, that scala-cli should keep focusing on making the hard parts “easy enough”. It is orders of magnitude more useful to me that I can just do scala-cli setup-ide . and do script development in my IDE. | 10:12:54 |
| velvetbaldmime#6377 | IMO half a second to run hello world after it's been compiled is a noble thing to tackle | 10:13:08 |
| ragnar#4252 | For what its worth, I just wrote a different shebang runner when I needed the performance (or more specifically I did that about 1 month before I learned about scala-cli 😂 around the time when cs was enough of a thing that doing so was easy).
You basically gain most of what you want for that use case by just:
def scala3Runner(pathname: String, args: String*): Unit =
val path = Paths.get(pathname).toAbsolutePath
val hash = process"sha1sum $path".run().takeWhile(_ != ' ')
val target = cachedir.resolve(hash)
if Files.isDirectory(target) then new ProcessBuilder(s"$target/run" +: args).toIndexedSeq: _*).run()
else compile (which should actually be super easy now that we have scala-cli)
| 10:22:06 |
| ragnar#4252 | With which I just want to say, that shebang execution is pretty different from the rest of scala-cli usage, so it may be worth to just do the easy thing there 🤔 | 10:25:46 |
 mbesida | thanks, it is the same bug | 19:13:26 |
|  zebos#7602 changed their profile picture. | 19:57:24 |
| 25 Jan 2023 |
 lolgab#6138 | Not sure about this. I'm trying comparing bloop cli vs mill cli and they are almost the same, mill prints some instant earlier (assuming you can compare the Instant.now from two different processes reliably) | 16:33:25 |
| velvetbaldmime#6377 | But Mill is also daemonised, no? | 16:38:20 |
| velvetbaldmime#6377 | or is this with -i? | 16:38:30 |
| velvetbaldmime#6377 | My point was that connecting to an already running JVM with Zinc in it (Bloop or Mill server) is faster than shelling out to a whole new java command with Zinc | 16:39:13 |
| lolgab#6138 | Yeah, Then I didn't read the comment correctly, I thought that bloop had extra things that other build tools don't have. Yes it's exactly that, having an already warmed up zinc makes the difference | 16:56:25 |
| ragnar#4252 | I think the discussion was bloop vs scalac. | 18:03:47 |
| ragnar#4252 | Or more specifically, scala-cli using bloop vs scala-cli using whatever it does with --server=false which very well may still be bloop, just without the daemon. | 18:04:33 |
| lolgab#6138 | Yeah, I understood now, what I was understanding was that bloop had something that made it faster than vanilla zinc, which is not the case in my experience. | 18:07:01 |
| 26 Jan 2023 |
 armanbilge#6192 | I remember someone reporting a similar issue recently in #scala-native | 08:26:33 |
| velvetbaldmime#6377 | https://github.com/scala-native/scala-native/issues/3098 | 08:27:12 |
