GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||||
GeezerVison is showing github.com — GH-141148: Ensure decimal.getcontext() returns fresh copy. by nascheme · Pull Request #151953 · python/cpython Conversation
|
|
Checking the performance impact of this, for asyncio tasks. I'm not concerned about threads since starting a thread should be much more expensive than copying decimal.Context. Here is an analysis from GPT 5.6: Clang -O3, normal GIL build:
So the incremental first-use isolation cost was about 220–300 ns per task here. A deliberately tiny task doing nothing except accessing decimal slowed by about 14%; realistic tasks should amortize that quickly. There is also a steady-state cost of roughly 6 ns per current-context lookup from checking the depth. A basic decimal-addition benchmark did not show a measurable slowdown, although code-layout noise makes such tiny differences difficult to isolate. The C decimal Context grew from 120 to 128 bytes, and each contextvars.Context from 80 to 88 bytes on this build. Generalizing beyond tasks: the copy occurs once for each distinct copied contextvars.Context that first accesses an inherited decimal context. Arbitrary callbacks that capture separate contexts can therefore also each incur one copy, but asyncio task resumptions explicitly reuse the task’s existing context. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
This PR is stale because it has been open for 90 days with no activity. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.