Slow start of CLI, missing the supersonic effect

[rsvoboda]

Quarkus CLI has slow(-ish) start, I'm missing the supersonic effect.

I'm using MBP 2019 with JDK 11 and the cli startup feels slow, 2 seconds to get help.

Did also comparison with CLI for Spring Boot and Micronat to get help text and to get version. Micronaut cli is slower than Quarkus cli, but Spring Boot cli is much faster, around 0.6s versus 1.7s. I think Quarkus cli should get under 1 second.

Version:

time java -jar devtools/cli/target/quarkus-cli-999-SNAPSHOT-runner.jar  --version
Client Version 999-SNAPSHOT
java -jar devtools/cli/target/quarkus-cli-999-SNAPSHOT-runner.jar --version  1.71s user 0.18s system 178% cpu 1.058 total

time java -jar ~/Downloads/spring-2.5.1/lib/spring-boot-cli-2.5.1.jar --version
Spring CLI v2.5.1
java -jar ~/Downloads/spring-2.5.1/lib/spring-boot-cli-2.5.1.jar --version  0.57s user 0.10s system 107% cpu 0.630 total

Help:

time java -jar devtools/cli/target/quarkus-cli-999-SNAPSHOT-runner.jar  --help
Usage: quarkus [-ehv] [--verbose] [COMMAND]
  -e, --errors    Display error messages.
  -h, --help      Show this help message and exit.
  -v, --version   Print version information and exit.
      --verbose   Verbose mode.
Commands:
  create           Create a new project.
    app            Create a Quarkus application project.
    cli            Create a Quarkus command-line project.
  build            Build the current project.
  dev              Run the current project in dev (live coding) mode.
  extension, ext   List, add, and remove extensions of an existing project.
    add            Add extension(s) to this project.
    list, ls       List platforms and extensions for this project.
    remove, rm     Remove extension(s) from this project.
  completion       bash/zsh completion:  source <(quarkus completion)
  version          Display version information
java -jar devtools/cli/target/quarkus-cli-999-SNAPSHOT-runner.jar --help  1.75s user 0.21s system 126% cpu 1.552 total

time java -jar ~/Downloads/spring-2.5.1/lib/spring-boot-cli-2.5.1.jar --help
usage: spring [--help] [--version]
       <command> [<args>]

Available commands are:

  run [options] <files> [--] [args]
    Run a spring groovy script

  grab
    Download a spring groovy script's dependencies to ./repository

  jar [options] <jar-name> <files>
    Create a self-contained executable jar file from a Spring Groovy script

  war [options] <war-name> <files>
    Create a self-contained executable war file from a Spring Groovy script

  install [options] <coordinates>
    Install dependencies to the lib/ext directory

  uninstall [options] <coordinates>
    Uninstall dependencies from the lib/ext directory

  init [options] [location]
    Initialize a new project using Spring Initializr (start.spring.io)

  encodepassword [options] <password to encode>
    Encode a password for use with Spring Security

  shell
    Start a nested shell

Common options:

  --debug Verbose mode
    Print additional status information for the command you are running

See 'spring help <command>' for more information on a specific command.
java -jar ~/Downloads/spring-2.5.1/lib/spring-boot-cli-2.5.1.jar --help  0.60s user 0.11s system 109% cpu 0.641 total

[ebullient]

Could be related to #16355

[fercomunello]

@rsvoboda I figured out what is causing this strange behaviour on macOS systems when using Java CLI or starting Java apps in general.

The problem is that for some unknown reason, the following call on the JVM is taking seconds to execute:

java.net.InetAddress.getLocalHost()

It could be solved by adding the hostname that the application will return on your etc hosts file, pointing to 127.0.0.1 like: $ sudo nano /etc/hosts

127.0.0.1   localhost [your macOS hostname]
::1         localhost [your macOS hostname]

To see your actual hostname, run: $ hostname

I don't know in what JDK versions this problem happens, but I tested on Java LTS versions (11 & 17).

After change hosts file, you can just run Quarkus Fast-Jar and the startup time will be very fast as it should be: java -jar target/quarkus-app/quarkus-run.jar

In my case it's now just taking 0.553 seconds!!! Before I change the etc/hosts file, the startup was taking about 5 seconds.

If you're curious, you can run the Main class of inetTester.jar to see how much time the call takes to execute:

public static void main(String[] args) throws UnknownHostException {
    System.out.printf("Calling the hostname resolution method...%n");

    final Instant start = Instant.now();
    final String hostName = InetAddress.getLocalHost().getHostName();
    final long end = Duration.between(start, Instant.now()).toMillis();

    System.out.printf("Method called, hostname %s, elapsed time: %d (ms)%n", hostName, end);
}

[rsvoboda]

Hostname resolution trick is not helping in my case. In the description you can see that I have quick starts with other java programs. I will try to ping some people to see how quick time quarkus --help is on their systems.

[rsvoboda]

Ah, so I guess I found the trouble, I'm using quarkus app through jbang as described in https://quarkus.io/get-started/ and https://quarkus.io/guides/cli-tooling#installing-the-cli

When I directly invoke java -jar I have much better times:

java -jar devtools/cli/target/quarkus-cli-999-SNAPSHOT-runner.jar  1.50s user 0.16s system 168% cpu 0.987 total
jbang run devtools/cli/target/quarkus-cli-999-SNAPSHOT-runner.jar  3.90s user 0.42s system 183% cpu 2.356 total

cc @maxandersen

[maxandersen]

Yes. Two runs of a jvm vs one will have this effect.

I don't see the same big difference though.

What java version are you using ?

[rsvoboda]

Two runs of a jvm - yup, I realized that when looking into the details, was using GraalVM CE 21.3.0 Java11.

The main concern is that the JBang way of using quarkus is promoted in https://quarkus.io/get-started/ It's also first option in https://quarkus.io/guides/cli-tooling#installing-the-cli

So this way users get a slower experience with CLI than if they use for example SDKMAN! based CLI installation.

[maxandersen]

correct its slightly slower but it is also way simpler and more reliable to install.

working on making jbang native which should help too and provide java based fallback so still reliable to install. But its not in the cards at the moment.

[quarkus-bot[bot]]

/cc @ebullient, @maxandersen

[izderadicka]

Quite slow on WSL2 with Ubuntu 20

time quarkus --help
...
real    0m2.948s
user    0m5.507s
sys     0m0.898s

version 3.5.0

[maxandersen]

How is it installed ?

[izderadicka]

@maxandersen JBang

[maxandersen]

Ok. Try use direct sdk or scoop or choco. That removes one jvm start from that.

Try measure that and see what diff that does for you.

[izderadicka]

Bit better with sdk, about half:

time quarkus --help
...
real    0m1.387s
user    0m2.978s
sys     0m0.760s