experiment with using clap (builder API version) #4056
Conversation
|
This version has basically no compile time cost for me -- old: 2.2s, new: 2.4s. (The other PR makes it 3.1s. I don't know why it is so much faster now than last time I checked, maybe I did those benchmarks on battery?) |
|
A lot of the overhead here is caused by building the But, still... I am inclined to go with the nice version. This will only be rebuilt when people update their nightly Rust, i.e. at most once a day, likely less often. |
|
I agree with going with the derive API. It simplifies the code a lot, and the slowdown is not horrendous. If it proves to be annoying we can always reconsider later. |
|
Thanks for the investigation. I'm good with the derive version. |
|
Okay, closing in favor of #4036. Thanks @Mandragorian for exploring this option! |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DISCLAIMER
part of this PR was generated using chatGPT. specifically the
build_clifunction, and the code that translates the parsedmatchesto aCommand. I have read the generated code and modified slightly. I understand this might raise some questions, but I wanted to have a quick PoC since we haven't committed to anything.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I was wrong and it seems that the compilation is notably faster (2.6s master, 3s builder API, 3.7s derive API).
On the other hand as mentioned in #4036 the code is more complex. There is even a degree of duplication since we have to not only define the parser, but then also translate the
matchesinto aCommand.Also note that
clapintroduces ahelpsubcommand, so that./miri --helpand./miri helpare equivalent. I don't know if there is a way to opt-out of this, but if it is a problem I can look further into it.As with the other PR this needs more polishing, which I can do when we decide what we want to do.