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

extreme slow down in in_tz after upgrading from 2.1.2 to 3.0.0 #818

Open
adam006 opened this issue Apr 14, 2024 · 3 comments
Open

extreme slow down in in_tz after upgrading from 2.1.2 to 3.0.0 #818

adam006 opened this issue Apr 14, 2024 · 3 comments

Comments

@adam006
Copy link

adam006 commented Apr 14, 2024

  • [x ] I am on the latest Pendulum version.
  • [ x] I have searched the issues of this repo and believe that this is not a duplicate.
  • OS version and name: Mac OS 14.4.1 (23E224)
  • Pendulum version: 3

Issue

Hello, we have recently upgraded to pendulum 3 from 2.1.2 and have noticed an extreme slow down in one of our processes that has to compute a lot of times (a few hundred thousand) in version 2 it would take about ~2 minutes after switching to the latest pendulum version I end up killing the process after about 15 minutes. Doing some investigation I can see it is happening within the in_tz call and when changing the code to use astimezone it drops down to about ~43 seconds. Also creating a new project and doing a simple pyinstrument test on the in_tz function with a single timezone shows the following speed change
old - pendulum_2 1 2 new -
pendulum_3 0.
We have pendulum used a lot through the project and are concerned about this slow down within pendulum and do not want to have to rewrite the project to remove it, due to how highly integrated it is with pendulum. What can we do about fixing the speed issues here?

@adam006
Copy link
Author

adam006 commented Apr 15, 2024

I was able to improve this slightly by patching the timezone function and caching the Timezone objects but it is still very slow and demands a lot of cpu.

@adam006
Copy link
Author

adam006 commented Apr 15, 2024

more investigation shows that this call to convert on this line specifically with the dt.astimezone(self), which appears to be a builtin function, however like I stated above using the call to astimezone directly takes almost nothing. That makes this all the more perplexing.

@ariebovenberg
Copy link

This must indeed be an inadvertent regression—the pendulum FAQ shows pendulum's performance was way faster than arrow, but now it seems reversed:

...........
tz change (pendulum): Mean +- std dev: 58.0 us +- 0.6 us
...........
tz change (stdlib): Mean +- std dev: 233 ns +- 2 ns
...........
tz change (arrow): Mean +- std dev: 4.67 us +- 0.06 us

benchmark source:

import pyperf

runner = pyperf.Runner()
runner.timeit(
    "tz change (pendulum)",
    "dt.in_tz('America/New_York')",
    setup="from pendulum import datetime; dt = datetime(2020, 3, 20, 12, 30, 45, tz='Europe/Amsterdam')",
)
runner.timeit(
    "tz change (stdlib)",
    "dt.astimezone(target)",
    setup="from datetime import datetime; from zoneinfo import ZoneInfo; "
    "dt = datetime(2020, 3, 20, 12, 30, 45, tzinfo=ZoneInfo('Europe/Amsterdam')); "
    "target = ZoneInfo('America/New_York')",
)
runner.timeit(
    "tz change (arrow)",
    "dt.to('America/New_York')",
    setup="import arrow; dt = arrow.get(2020, 3, 20, 12, 30, 45, 0, tz='Europe/Amsterdam'); "
)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants