Skip to content
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

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

Open
wants to merge 10 commits into
base: master
from

Conversation

@pganssle
Copy link
Member

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 pganssle force-pushed the pganssle:tzidx_poc branch from 9020a04 to 137ee71 Jan 13, 2019
@pganssle

This comment has been minimized.

Copy link
Member Author

pganssle commented Jan 13, 2019

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.

@pganssle pganssle force-pushed the pganssle:tzidx_poc branch from fe45b5e to c591a33 May 7, 2019
pganssle added 10 commits Jun 4, 2018
As with the other tzinfo methods, datetime.tzidx is now implemented in
terms of tzinfo.tzidx, with some additional strictness because of the
nature of the tzidx method.
@pganssle pganssle force-pushed the pganssle:tzidx_poc branch from c591a33 to b1e28e3 May 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.