-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
feat: improve make_date
performance
#9112
Conversation
Signed-off-by: Nikolay Ulmasov <[email protected]>
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.
I think this PR would be good to go once CI passes |
make_date
performance
I also ran the benchmarks: git checkout a6ef1bec480872f15f83628a7fb8c9bb2722cd49 # merge-base results are basically the same as yours:
🚀 |
Yes, I had some regression on all scalar test ( |
Nice - that's a pretty big performance improvement! |
The
variable could now be removed and the for loop could just use len.unwrap() I think. |
Sure, I can do that but |
Hmm, I think I missed that - the downside of looking at code outside of an IDE without proper highlighting. Please ignore my comment then :) I have to see if there is a way to look at and comment on these pull requests easily in rust rover. Hopefully they've brought that functionality over from IntelliJ IDEA. |
I've not tried RustRover, mainly work with VSCode. I don't have JetBrains licenses and though RR is free for now, I don't want to put time into learning something I won't be able to use once it becomes paid-for 🤷 |
I believe this feature is present (though I normally just use the github UI or else check out the PR directly via |
I plan to merge this in tomorrow unless there are other comments |
Which issue does this PR close?
#9089. It may not close it but could be a stepping stone towards more optimal version.
Rationale for this change
The change shows significant bench performance improvement
What changes are included in this PR?
Changed the way the value is looked up in the array - instead of looking up each value by converting to PrimitiveArray, pre-created the instance of PrimitiveArray and used that in the loop
Are these changes tested?
Yes, all tests and example runs are passing
Are there any user-facing changes?
No user and API changes, tried to match the behavior to what it was (including returning errors)