X Tutup
The Wayback Machine - https://web.archive.org/web/20250416024015/https://github.com/python/cpython/pull/11529
Skip to content

bpo-35723: Proof of concept for tzidx cache #11529

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 10 commits into from

Conversation

pganssle
Copy link
Member

@pganssle pganssle commented Jan 11, 2019

When examining the performance characteristics of pytz, I realized that pytz's eager calculation of tzname, offset and DST gives it an implicit cache that makes it much faster for repeated queries to .utcoffset(), .dst() and/or .tzname(), see my blog post "pytz: The Fastest Footgun in the West", though the eager calculation means that it's slower to create an aware datetime that never calculates those functions.

This proof of concept introduces a "set once" cache to the datetime object that tzinfo implementations can use to cache offset and name lookups per datetime. A more thorough discussion of the rationale for this change is available on the associated issue, bpo-35723.

I will note that this is currently a WIP, it still needs:

  • Proper handling of what happens when this function is called in an infinite recursive loop (currently segfaults)
  • Tests for the situation where tzidx is not an integer, or outside the interval [0, 254]
  • Documentation of the API
  • News entry

https://bugs.python.org/issue35723

@pganssle pganssle changed the title Proof of concept: tzidx cache bpo-35723: Proof of concept for tzidx cache Jan 11, 2019
@pganssle
Copy link
Member Author

Hm, in an earlier version of this I got a segfault when I had some accidental recursion in the tzidx() implementation, but I could not reproduce this when I added the test.

I suppose for now I'll assume the segfault was for some other reason and that it is fixed now, but if anyone can come up with an example of a tzinfo implemented with recursion that causes a segfault, I'll add and fix it.

@github-actions
Copy link

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale Stale PR or inactive for long period of time. label Jul 29, 2022
@pganssle
Copy link
Member Author

I believe this is no longer necessary.

@pganssle pganssle closed this Apr 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DO-NOT-MERGE stale Stale PR or inactive for long period of time.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant
X Tutup