Picocli extension - consider generating command metadata during build

[mkouba]

ATM picocli builds the CommandSpec metadata using reflection every time the application is started. This is OK in most situations but may represent considerable overhead for applications that finish instantly, e.g. some Quarkus CLI commands. It might make sense to analyze the commands during build and either generate some "builder" classes or record the metadata (e.g. using AnnotationProxyBuildItem) and build the metadata in a recorder method.

[quarkus-bot]

/cc @ebullient, @gsmet, @maxandersen

[mkouba]

WDYT @mgorniew?

[gsmet]

Yeah I had the same thought the other day. I'm just unsure how much time it takes. Given displaying the help is slow enough even in native, I suppose it takes quite some time.

[mkouba]

I'm just unsure how much time it takes.

My super unreliable measurement showed that it could be hundreds of ms (quarkus cli has 1 top command + 10 subcommand classes).

[maxandersen]

Given displaying the help is slow enough even in native, I suppose it takes quite some time.

big part of this one is probably due the console width calculation which can be expensive even in native.

that said - i do think picoclis annotation parsing is quite slow - its signficiant in jbang too.

[mkouba]

Given displaying the help is slow enough even in native, I suppose it takes quite some time.

big part of this one is probably due the console width calculation which can be expensive even in native.

This part should be solved in #16320.

[remkop]

I’ve been wanting to do something like this: remkop/picocli#539 but never got around to it.

[remkop]

Yeah I had the same thought the other day. I'm just unsure how much time it takes. Given displaying the help is slow enough even in native, I suppose it takes quite some time.

Can you put some numbers on that? How long does displaying the help take in native and in JIT mode?

The reason I'm asking is to clarify what exactly is the problem that this ticket is trying to solve:

• What are the current execution times for the commands
• What are the target execution times for these commands?

[quintesse]

@remkop I don't have the exact numbers at hand (they're somewhere in a chat) but when I was investigating the slow startup of Jbang I found that around .6s of a 1.2s startup was due to Picocli setup. For a tool that's supposed to enable Java as a scripting language adding more than a second to the startup will make people think twice before dropping Perl/Node/Bash in favor of Java. As a comparison java and javac start up in about 0.1s and 0.3s so ideally we don't want to be adding too much on top of that. So remkop/picocli#539 is very interesting for us as well.

[ebullient]

Now that I've done the crazy things and restructured the entire CLI to be a little cleaner.. I could also just say eff the annotations and code it directly.

Annotations are cool and all, but we don't actually have to use them..
Is there a real reason to use them? Some secret benefit I'm not seeing?
(it would kind of re-uglify some things.. but if that is the tradeoff that needs to be made.. that's the tradeoff that needs to be made)

Need to now revisit native mode, too

[quintesse]

@ebullient I was considering the same for Jbang and my worry is that it will become less maintainable (somewhat ) and less accessible to people who are not familiar with the code.

[ebullient]

Annotations are magic .. and that can be less maintainable, too. Depends on how cleanly you can do it, I suppose. I don't necessarily find annotations any more readable (you have to know how they go together.. )

I have a few other things to chew through.. but I might try it and see how bad it gets.. I mean, I've already written the CLI once.. so it's all fresh in my head.. :-P

[maxandersen]

Annotations makes sense to be declarative and quarkus be smarter about it.

Even doing it programmatically will have an overhead compared to have the quarkus picocli extension do it during build and just load static model at startup.