Open maxandersen opened 3 years ago
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.
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.
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.
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.
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.
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).
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 ;)
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.
FTR with https://github.com/quarkusio/quarkus/pull/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 ;-).
/cc @ebullient
still relevant to explore; but its triaged right for now thus removing the need-triage label
Description
can we make qs cli native ? does it make sense ?