Low priority issue, but open for any interested party to attack.
Using guava stopwatch, I tracked the time to populate and build airline CliBuilder.build() at 108ms. The time to execute Cli.parse is 21ms. The parsing time is an order of magnitude less than processing, but together they amount to 130ms... 1/3 of the time inclusive of launching the JVM when using the mock provider!
Right now, remote provider calls include a heavy overhead due to the jclouds dependency and how its guice is wired. This overhead is so large that addressing the jclouds dep is a lower hanging fruit wrt performance and will be tackled in a separate issue.
That said, we'll at some point want to address CLI parsing overhead, particularly as jopt-simple overhead is 13ms or so. My suspicion is that the runtime annotation processing in airline is the cause for this overhead, and a Dagger-like approach could rid the excess.
Low priority issue, but open for any interested party to attack.
Using guava stopwatch, I tracked the time to populate and build airline
CliBuilder.build()
at 108ms. The time to executeCli.parse
is 21ms. The parsing time is an order of magnitude less than processing, but together they amount to 130ms... 1/3 of the time inclusive of launching the JVM when using the mock provider!Right now, remote provider calls include a heavy overhead due to the jclouds dependency and how its guice is wired. This overhead is so large that addressing the jclouds dep is a lower hanging fruit wrt performance and will be tackled in a separate issue.
That said, we'll at some point want to address CLI parsing overhead, particularly as jopt-simple overhead is 13ms or so. My suspicion is that the runtime annotation processing in airline is the cause for this overhead, and a Dagger-like approach could rid the excess.