-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Scheduler] Improve triggers performance when possible #49817
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
[Scheduler] Improve triggers performance when possible #49817
Conversation
Why do you think the original version was bad? The Now, there are two algos and "magic" with reflections... The goal of constructors is initialization of objects to a valid state. It's not a big deal, but having logic in a constructor except assertions of arguments is bad practice. Now it has too much "magic". The IMO it was better. |
47b35b8
to
fe266a5
Compare
537e357
to
55933a2
Compare
6e48389
to
c494148
Compare
c494148
to
f70a577
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cosmetic
f70a577
to
c80e9ad
Compare
c80e9ad
to
a53187f
Compare
1fe7222
to
ca3c30c
Compare
ca3c30c
to
ebcced6
Compare
Thank you @fabpot. |
Using
\DatePeriod
for the default trigger is great as it takes care of all date/time idiosyncrasies.But for high frequencies, that does not work well and performance becomes an issue. So, this PR solves this issue by always using the fast algorithm when the frequency is expressed in seconds (int) or an ISO period (like
PT2S
) or when created from a string that uses a "simple" expression (like2 seconds
)./cc @upyx