You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
extreme slow down in in_tz after upgrading from 2.1.2 to 3.0.0 #818
[ 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 - new - .
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?
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.
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.
Activity
adam006 commentedon Apr 15, 2024
I was able to improve this slightly by patching the
timezonefunction and caching theTimezoneobjects but it is still very slow and demands a lot of cpu.adam006 commentedon Apr 15, 2024
more investigation shows that this call to
converton this line specifically with thedt.astimezone(self), which appears to be a builtin function, however like I stated above using the call toastimezonedirectly takes almost nothing. That makes this all the more perplexing.ariebovenberg commentedon Apr 18, 2024
This must indeed be an inadvertent regression—the pendulum FAQ shows pendulum's performance was way faster than
arrow, but now it seems reversed:benchmark source:
ashb commentedon Apr 13, 2025
Confirmed this is still a problem - tested against dcd9816
And comparing to v2:
(Py 3.11 as Pendulum v2 didn't build out of the box on 3.12 and I didn't put any time into it)
We'll take a look at this soon, possibly after Airflow 3.0 is out and I'm less exhausted.