Ways to improve slow startup time

[quintesse]

From some extensive but very informal testing I did some time ago I found that the biggest part of Jbang's startup time is spent on initializing Picocli. So I've been thinking about ways to make things faster. Let's see if together we can come up with a solution.
These were my ideas:

1. Compile to native
2. Use Quarkus
3. Use Picocli API
4. Use something else than Picocli

For each of these options we have some pros and cons (and some cases only cons):

Compile to native

We could use GraalVM to compile Jbang to native code. We could distribute the binaries as part of the distribution .zip/.tgz and use the startup scripts to determine what we want to execute (binaries for the correct platform are available, use them, if not fall back to using the .jar).

The pro is that this probably results in the fastest code. The con is that we'd need to come up with a way to make the build integrations work. This could probably be done by falling back to the Java code when we need to build anything. If we made a special entry point that didn't use Picocli just for that purpose we could keep that functionality without giving up too much of the speed boost that native code would give us. Another con is that the distribution process would get more complicated (building native binaries etc).

Use Quarkus

This is the part I know least about. So I can't give a good analysis about pros and cons. Perhaps you can fill this in @maxandersen ?

Use Picocli API

The reason for this option is because I'm assuming that the slowness in setting up Picocli is because of all the annotations and introspection that's going on. Using the API would avoid all that.

The most obvious con is that the API is much harder to use than the annotations.

So one idea I had to mitigate that complexity is to keep using the annotations and create some kind of code generator that reads those annotations once and then turns that into code that uses the API.

The pro is that we'd get rid of the slowness while keeping the ease of maintenance that annotations give us. The big con of course is that creating that code generator is a very complex job in itself. (But it might be something the upstream would be willing to adopt once it works).

Use something else than Picocli

Not knowing any good alternatives this is basically just cons. Even if there is an alternative that isn't slow, switching to something else is a huge job.

[maxandersen]

There is an issue on quarkus repo about options for making picocli do it's scanning during build rather than at runtime.

Maybe if we could contribute to that work then moving to quarkus would be more interesting.

Advantages of quarkus is things would more easily compile to native. Downside is our dependnencies might be quite bigger - but need to test that.

[quintesse]

Ha! My point 3 is basically this: remkop/picocli#539

[quintesse]

Copying some "data" from old chats so we have some numbers at least:

So I was looking again a bit at what's making jbang slowish and I just can't explain it very well
I've done some very unscientific tests, basically just using a crude tool like time to see where most of the time was spent

So if I let jbang run a previously compiled helloworld it takes around 1.3s (on my system)
If I then run that code directly it's about 0.18s, so that's quite a big difference
I then pasted that line inside the shell script where normally jbang would be called to see how much the script would add
And it's basically the same (within the very crude timing provided by time)

I then reverted that line back to normal and commented out the entirety of Jbang's Main.main().
So Jbang would be called but would do nothing
That resulted in a time of around 0.12s, so that's calling jbang from the startup script with it doing nothing
Then I combined those two, so calling a do-nothing jbang and hard-coding the result to be executed
That would be like a best-case scenario where calling jbang and getting it's result would take almost 0 time
And it gives me around 0.27s

Going back to a normal jbang and running it with a do-nothing command like version still gives around 0.8s
Which I thought was just ridiculous, how are we going from 0.12s for jbang doing nothing to 0.8s for it printing the version?
I then again started paring down the Main.main() basically only leaving the very first line: CommandLine cli = Jbang.getCommandLine()
And that takes on average 0.77s!

So setting up the command line without having actually executed any of our own code yet is taking 0.65s??

It does mean that we still have another 0.65s (1.3s - 0.65s) that we can improve on, which is in our own code. BUt that half is seemingly taken by picocli surprises me. Perhaps because of all the introspection?