Repository navigation
Measure if _warnings.c is still worth having #69126
Description
| BPO | 24938 |
|---|---|
| Nosy | @brettcannon |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/brettcannon'
closed_at = <Date 2015-09-06.18:42:28.459>
created_at = <Date 2015-08-25.18:49:27.517>
labels = ['performance']
title = 'Measure if _warnings.c is still worth having'
updated_at = <Date 2015-09-06.18:42:28.457>
user = 'https://github.com/brettcannon'bugs.python.org fields:
activity = <Date 2015-09-06.18:42:28.457>
actor = 'brett.cannon'
assignee = 'brett.cannon'
closed = True
closed_date = <Date 2015-09-06.18:42:28.459>
closer = 'brett.cannon'
components = []
creation = <Date 2015-08-25.18:49:27.517>
creator = 'brett.cannon'
dependencies = []
files = ['40269']
hgrepos = []
issue_num = 24938
keywords = ['patch']
message_count = 4.0
messages = ['249150', '249152', '249213', '250004']
nosy_count = 1.0
nosy_names = ['brett.cannon']
pr_nums = []
priority = 'low'
resolution = 'works for me'
stage = 'needs patch'
status = 'closed'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue24938'
versions = ['Python 3.6']
Activity
brettcannon commentedon Aug 25, 2015
_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.
brettcannon commentedon Aug 25, 2015
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.
brettcannon commentedon Aug 26, 2015
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 -c1000 timesINFO:root:Running
../cpython/pristine/python.exe -c1000 timesRunning startup_nosite...
INFO:root:Running
../cpython/default/python.exe -S -c2000 timesINFO:root:Running
../cpython/pristine/python.exe -S -c2000 timesReport 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.
brettcannon commentedon Sep 6, 2015
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.