-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
[HOLD for payment 2023-10-30] parseISO from date-fns is pretty slow, we can replace parseISO from date-fns with Date() #29271
Comments
Hey, Im Artem from Callstack and would like to help with this one |
Hey @mountiny, this PR is ready for review |
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.88-11 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2023-10-30. 🎊 After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.
For reference, here are some details about the assignees on this issue:
As a reminder, here are the bonuses/penalties that should be applied for any External issue:
|
Triggered auto assignment to @isabelastisser ( |
Bug0 Triage Checklist (Main S/O)
|
this is ready to pay $500 to @fedirjh for their review and testing! @isabelastisser thank you! |
Hey @fedirjh, I sent you the offer in Upwork. Please accept it, and I will process the payment ASAP. Thanks! All set, closing. |
Problem:
date-fns is a great library but it’s underperforming in some scenarios For example, using parseISO function takes around 112 ms and it’s a lot of time for a utility function. The main problem we have at our hands is most of the work is already been done in moving from moment to date-fns . While date-fns is a good library and works well in other scenarios, which otherwise haven’t been reported by profiler but parseISO is such a utility function which is consuming noticeable milliseconds and reported by profiler.
Solution:
We have two solutions here:
Given our efforts in migrating from moment to date-fns , we can use stock new Date(dateToParse) in place of parseISO and it works really well. Looking at the benchmarks, parseISO can perform around 69-71k operations per second, whereas new Date can perform around 379k operations per second.
We can introduce dayjs which we can use in place of parseISO and in rest of the places we can still use date-fns unless in future if Profiler states to us that this certain function is slow, so we can gradually replace date-fns from the codebase. In our codebase, we are using this parseISO function in only a couple of places and we can easily refactor the codebase. A good alternative to date-fns is dayjs and it’s also a lighter one, only 2KB in size. Using dayjs in place of parseISO function, we see that it takes around 23 ms in Profiler. Also, if we take a closer look at the comparisons benchmarks, parseISO can perform around 69-71k operations per second, whereas dayjs can perform around 167k operations per second, which is a lot of difference.
Since we have spent a lot of efforts in migrating from moment to date-fns and certainly it’s better than moment but in some scenarios, some utility functions of date-fns are underperforming. Ideally, we can replace those underperforming parts with new Date and in future, if there are any other underperforming utility functions reported by Profiler, we can decide whether it’s fixable by using stock Date or now it is time to gradually adopt dayjs or any other efficient date library.
The text was updated successfully, but these errors were encountered: