Passing down the App version to the help/version commands

[daudef]

I have a performance issue where it takes 500ms to get help message from my app while it only has 6 subcommand, but nested on 3 levels, so I am creating quite a few App objects. I've tracked it down to 400ms worth of inspect.getmodule calls from _get_root_module_name. This is due to the fact that every time an App object is initialized, it will create 2 commands for --help and --version which initialize 2 new App object without specifying the version, so it will call the version factory 2 times which makes inspect.getmodule calls.

So my fix just pass down the version from the app to the commands.

[BrianPugh]

Thank you! I really need to get around to profiling real world situations like this. What % of the launch time did this take up? Is there any other low hanging optimizations?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.49%. Comparing base (8817d98) to head (7efd334).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #217   +/-   ##
=======================================
  Coverage   95.49%   95.49%           
=======================================
  Files          23       23           
  Lines        2107     2107           
  Branches      539      539           
=======================================
  Hits         2012     2012           
  Misses         46       46           
  Partials       49       49           

Flag	Coverage Δ
unittests	95.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[daudef]

The import time (under the profiler) of my app went from 714ms to 204ms, so quite a lot 😅. I don't think there is any other significant optimizations for the App instantiation since the time spent instantiating went from 513ms to 0.424ms. The main __call__ call is at 84ms, not really an issue in my case, and it spends 27ms in format_str, 25ms in rich render and 24 ms in _resolve_console so i don't think it is easily optimisable.