I’ve written a selection sort of 10 integers in scala and F#.
scala “sbt run” takes 15 seconds.
F# “dotnet run” takes 0.9 seconds.
How can i improve this speed.
Can i create a self-contained assembly to start faster ? How to do ?
There are scads of ways to speed it up, ranging from compiling with Graal to going to Scala Native, to pre-building your assembly, to using scala-cli or Ammonite instead of sbt, to simply leaving sbt running and invoke “run” inside of it (which is how I spend essentially all day, every day).
But to be clear: it’s rare for anybody to run real production systems with “sbt run”, and it’s a bit unusual for startup time to matter all that much in the real world. (There are examples where it matters, of course, but in 12 years of full-time Scala I’ve never worked on a system where that was a relevant consideration.)
So the question is, what are you trying to do? It’s true that “sbt run” is a super-heavyweight way to start an application, just about the worst possible; which alternative you choose depends on what your needs are. The right answer for a tiny command-line utility is usually very different from that for a beefy enterprise data-processing server, and very different from interactive development.
2 Likes
How do i prebuild an assembly ?
What is an example build.sbt file to create one ?
Which commands to create one ?
Which commands to run one ?
(In F# you can do “dotnet publish” which creates a self-contained output-file to run)
It’s been a fair number of years since I’ve played with it, but the sbt equivalent, last I checked, is the sbt-assembly plugin.
But again, it’s all about use cases. sbt-assembly is primarily about creating a shippable JAR, rather than speed. And it touches on a lot of complexity, because it leads you to think about things like merge strategies, shading, and stuff like that. I think of it primarily as a tool for deploying enterprise software.
So when you talk about doing a little sort program, it’s almost certainly the wrong tool for the job – using the proverbial sledgehammer to swat a fly.
1 Like
I would think sbt-native-packager is a better option
1 Like
Might well be – like I said, it’s been ages since I’ve last played with these.
When i use a postgresql database connection i cannot use sbt-native-packager.
I managed to use sbt-assembly , it needed just one right configuration line.
Running the application now dropped from 15 seconds with sbt to 0.2 seconds with java -jar …
3 Likes
I’m curious: Are you sure about that? What makes you think so?
(Regardless, glad you got sbt-assembly working!)
1 Like
Consider using Coursier, as per this example.
That builds an executable via the invocation sbt packageExecutable on the command line.
EDIT: @alain - I imagine you’re just mucking around with Scala at the moment to get a feel for what’s what. Ignore my advice here and go with what @spamegg1 wrote further on, it’s more suitable…
2 Likes
I know this thread is about sbt, but scala-cli makes it very easy to package things. The Scala Native option can even give you a binary executable that can run without java.
If you are just starting or doing simple things like a basic sorting algo, then Scala-cli is the tool of choice.
6 Likes
scala-cli is very usefull when you don’t have external libraries/dependencies.
But it is difficult with only one external libraries/dependency
I think a good amount of time goes into sbt’s own startup time. You can use scala-cli to run your code. Also sbt has a console which you drop into by just using sbt command in your project’s root directory. Then use runMain <class> to run the program.
2 Likes
Eh? I’m not sure how you got that impression.
My best guess is that you’re confusing the old scala command from years past with the current one. The current scala command runs scala-cli, https://scala-cli.virtuslab.org/
Most scala-cli users have dependencies; it’s designed for that.
For example, one of my scala-cli scripts has:
//> using dep com.sun.xml.parsers:jaxp-ri:1.4.5
//> using dep org.apache.commons:commons-text:1.10.0
those two lines in my .scala file are all that’s needed to bring in those dependencies.
The full doc on dependencies in scala-cli is at Managing dependencies | Scala CLI
5 Likes