-
-
Notifications
You must be signed in to change notification settings - Fork 9.8k
[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
chalasr
left a comment
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
\DatePeriodfor 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