make cli native

[maxandersen]

Description

can we make qs cli native ? does it make sense ?

[FroMage]

It MUST be native. On my machine it took this time:

 $ time qs
Usage: quarkus [-ehV] [--verbose] [COMMAND]
  -e, --errors    Produce execution error messages.
  -h, --help      Show this help message and exit.
  -V, --version   Print version information and exit.
      --verbose   Verbose mode.
Commands:
  build             Build your quarkus project
  clean             Clean current project
  create            Create a new quarkus project.
  create-jbang      Create a new quarkus jbang project.
  list              List installed (default) or installable extensions.
  platforms         List imported (default) or all available Quarkus platforms.
  add               Add extension(s) to current project.
  remove, rm        Remove an extension from this project.
  dev               Execute project in live coding dev mode
  create-extension  Creates the base of a Quarkus extension in different layout depending of the options and environment.

real	0m1.625s
user	0m3.663s
sys	0m0.266s

That's unacceptable for a CLI.

[gsmet]

This is what I have with native:

 gsmet  tmp  tests-cli  $  time ~/git/quarkus/devtools/cli/target/quarkus-cli-999-SNAPSHOT-runner 
Usage: qs [-ehV] [--verbose] [COMMAND]
  -e, --errors    Produce execution error messages.
  -h, --help      Show this help message and exit.
  -V, --version   Print version information and exit.
      --verbose   Verbose mode.
Commands:
  build             Build your quarkus project
  clean             Clean current project
  create            Create a new quarkus project.
  create-jbang      Create a new quarkus jbang project.
  list              List installed (default) or installable extensions.
  platforms         List imported (default) or all available Quarkus platforms.
  add               Add extension(s) to current project.
  remove, rm        Remove an extension from this project.
  dev               Execute project in live coding dev mode
  create-extension  Creates the base of a Quarkus extension in different layout depending of the options and environment.

real	0m0.350s
user	0m0.033s
sys	0m0.072s

It's not amazingly fast tbh. I would have expected our command line support to be faster (especially to just display the help).

But in any case, the real commands will do a lot more work and network accesses so they will be slow anyway.

[maxandersen]

Being fast to show help isn't critical Imo. Try compare it to what same create commands using mvn and Gradle does. Then CLI jvm doesn't feel slow and the native startup time doesn't make a big difference. I thus still consider it nice/good to have not a must.

[maxandersen]

I.e. if the option is between not releasing any cli vs having A jvm cli that is much faster than mvn/Gradle I would go for cli jvm.

[maxandersen]

okey so now at keyboard to do runs on my machine:

maven:
mw io.quarkus:quarkus-maven-plugin:1.13.0.Final:create -Dextensions="vertx" 5.38s user 0.58s system 244% cpu 2.438 total

jar direct:
java -jar create 4.09s user 0.35s system 164% cpu 2.695 total

qs via jbang (expected some overhead but not that noticeable in create call)
qs create 2.79s user 0.33s system 178% cpu 1.749 total

so 2.79s vs 5.38s and funny enough mvn felt faster as it was printing things out earlier - but thats subjective :)

can it get improved ? probably - and I do actually think there must be something "too heavy" initialized.

still think this is way better to have to avoid requiring mvn overhead.

[FroMage]

You can't possibly compare this to other JVM commands: everyone laments how slow they are to start.

I do agree it's acceptable to start with a JVM version if we can't pull off a native one in time due to time constraints, but we should fix this and get something that bears comparison with other command-line apps (non-JVM).

[FroMage]

It's not amazingly fast tbh. I would have expected our command line support to be faster (especially to just display the help).

Still 5 times faster than the JVM version ;)

[maxandersen]

I do agree it's acceptable to start with a JVM version if we can't pull off a native one in time due to time constraints, but we should fix this and get something that bears comparison with other command-line apps (non-JVM).

100% agree - thats all I've been saying. lets look into it but dont make it the first priority. i/we spent ungawdly amount of time initailly on the cli as everyone seem insisting on it had to be native when windows native wasnt even possible; and I just dont want us to keep "hanging" on it being native as there are much more impactful things that keeps lagging.

[mkouba]

FTR with #16320 and native I get:

time ./target/quarkus-cli-999-SNAPSHOT-runner 
...
real	0m0,016s
user	0m0,011s
sys	0m0,007s

compared to:

time ./target/quarkus-cli-999-SNAPSHOT-runner 
...
real	0m0,330s
user	0m0,026s
sys	0m0,042s

I agree with Guillaume that most real commands will be slow anyway. However, I believe that we should really improve the startup time for simple commands because it just doesn't look good ;-).

[quarkus-bot]

/cc @ebullient

[maxandersen]

still relevant to explore; but its triaged right for now thus removing the need-triage label