This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Measure if _warnings.c is still worth having
Type: performance Stage: needs patch
Components: Versions: Python 3.6
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: brett.cannon Nosy List: brett.cannon
Priority: low Keywords: patch

Created on 2015-08-25 18:49 by brett.cannon, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
issue24938.diff brett.cannon, 2015-08-26 19:57 Hack to create _frozen_warnings review
Messages (4)
msg249150 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2015-08-25 18:49
_warnings.c was initially created to help with startup performance. It turned out to be a tricky bit of code to get right to continue to support the Python version of the module.

But now that we live in a world where we have startup benchmarks instead of hunches and we freeze code like importlib, maybe it's time to re-evaluate whether warnings.py is such a bad thing to have as part of the startup process? I would be curious to know what the performance impact is if we made _warnings the frozen version of warnings.py instead of the C code and measured the startup performance.
msg249152 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2015-08-25 18:53
I should also mention the other motivating factor was providing C access to the warnings system, but once again importlib blazed that trail already by providing a C API which simply uses the Python code.
msg249213 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2015-08-26 19:57
Here are the benchmark results of freezing warnings.py as _frozen_warnings (very quick hack which doesn't use _frozen_warnings is attached). Basically -S slows down by about 3% and normal startup has no measurable impact. Not sure if that's worth it to simplify the warnings code or not.


INFO:root:Automatically selected timer: perf_counter
INFO:root:Skipping benchmark bzr_startup; not compatible with Python 3.6
INFO:root:Skipping benchmark hg_startup; not compatible with Python 3.6
Running normal_startup...
INFO:root:Running `../cpython/default/python.exe -c ` 1000 times
INFO:root:Running `../cpython/pristine/python.exe -c ` 1000 times
Running startup_nosite...
INFO:root:Running `../cpython/default/python.exe -S -c ` 2000 times
INFO:root:Running `../cpython/pristine/python.exe -S -c ` 2000 times

Report on Darwin Bretts-MacBook-Pro.local 14.5.0 Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64 i386
Total CPU cores: 4

### startup_nosite ###
Min: 0.311247 -> 0.317280: 1.02x slower
Avg: 0.316682 -> 0.325945: 1.03x slower
Significant (t=-17.89)
Stddev: 0.00326 -> 0.00403: 1.2360x larger

The following not significant results are hidden, use -v to show them:
normal_startup.
msg250004 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2015-09-06 18:42
After thinking about it and with _warnings.c not exactly changing very much I think I'm going to call YAGNI on ripping out _warnings.c.
History
Date User Action Args
2022-04-11 14:58:20adminsetgithub: 69126
2015-09-06 18:42:28brett.cannonsetstatus: open -> closed
resolution: works for me
messages: + msg250004
2015-08-26 19:57:58brett.cannonsetfiles: + issue24938.diff
keywords: + patch
messages: + msg249213
2015-08-25 18:53:55brett.cannonsetmessages: + msg249152
2015-08-25 18:49:38brett.cannonsetassignee: brett.cannon
2015-08-25 18:49:27brett.cannoncreate