Message306723
| Author |
vstinner |
| Recipients |
Decorater, jbfzs, ncoghlan, r.david.murray, rhettinger, serhiy.storchaka, vstinner, Александр Карпинский |
| Date |
2017年11月22日.11:29:35 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1511350175.11.0.213398074469.issue27535@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
The performance bottleneck of warnings.warn() is the dance between the C _warnings module and the Python warnings module. The C code retrieves many attributes, like warnings.filters, at each call, and does conversion from Python objects to C objects.
There is already a mecanism to invalidate a "cache" in the C module: warnings._filters_mutated() is called by warnings.filterwarnings() for example.
Maybe the C module could convert all filters at once into an efficient C structure, but throw this away once on cache invalidation.
The problem is that I'm not sure that it's ok to implement such deeper cache at C level. Is it part of the warnings "semantics" to allow users to modify directly warnings.filters? Must the C module always lookup in sys.modules if the 'warnings' modules didn't change?
Outside test_warnings, do you know an use case where lookup for the 'warnings' module and 'warnings.filters' must be done at *each* warnings.warn() call? |
|