| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks, look good!
This is somewhat marginal. On my laptop, the time it takes to import warnings is below the noise floor. On another system I have access to, it looks like it's about 0.3ms. (Both measuring Python 3.11 builds)
λ hyperfine --warmup 3 'python -c "pass"' 'python -c "import warnings"'
Benchmark 1: python -c "pass"
Time (mean ± σ): 39.0 ms ± 1.4 ms [User: 30.8 ms, System: 8.3 ms]
Range (min … max): 34.4 ms … 41.3 ms 78 runs
Benchmark 2: python -c "import warnings"
Time (mean ± σ): 39.3 ms ± 1.9 ms [User: 28.9 ms, System: 10.4 ms]
Range (min … max): 30.4 ms … 47.0 ms 69 runs
Summary
python -c "pass" ran
1.01 ± 0.06 times faster than python -c "import warnings"
Sorry, something went wrong.
|
Yeah, definitely not the biggest contributor to import-time issues, but probably one of the easiest to tackle :) Thanks for the review! |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
warnings is a pretty cheap import, so the import-time saving from deferring it is usually pretty minimal. However, it's also a textbook example of an import that should be deferred wherever reasonable. Most of the time, it's only imported so that a DeprecationWarning can be emitted, and we should try to make it so that users only have to pay the (small) performance penalty from it being imported if they actually hit the specific code path that's deprecated.
Nonetheless, since the performance impact of importing warnings is so small, I've tried to avoid modules that make multiple uses of warnings -- it's not particularly DRY to have import warnings repeated several times in the same module. The one exception I made here is argparse: argparse really should be importing the absolute minimum set of modules given that it's a CLI framework (see #74338 for previous discussion).