-
Notifications
You must be signed in to change notification settings - Fork 736
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
Optimize Performance with Caching for Resolved Options and Parsed Locale Strings #1642
Conversation
… parsed locale strings - Implement caching to avoid redundant computations of resolved options and locale parsing. - Introduce a final `isEnglish` variable to efficiently check if the locale supports English. Signed-off-by: nodify-at <21654050+nodify-at@users.noreply.github.com>
Is there any update on this or can someone give me a feedback if I've to improve this PR? :) |
Once this one is merged, could we expect a new release ? There has been many perf improvements that would benefits to the community. |
I'll take a look at this one soon |
Thanks @icambron :) |
Nice work! I was just investigating this problem myself and stumbled upon this issue. Definitely looking forward to this performance improvement! 🚀 |
Hi @icambron, When would you have time to review this? We're using a temporary patch right now, and it would be great to have this feature in Luxon. This will help us remove the workaround and benefit the community, especially for Node.js apps. Thanks! |
src/impl/locale.js
Outdated
@@ -374,14 +394,14 @@ export default class Locale { | |||
this.eraCache = {}; | |||
|
|||
this.specifiedLocale = specifiedLocale; | |||
this.fastNumbersCached = null; | |||
this.fastNumbersCached = supportsFastNumbers(this); |
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 guess I don't quite know what moving this here is fixing. We may never use fastNumbers(), so I don't love the idea of computing it upfront instead of computing it lazily and only caching it then.
src/impl/locale.js
Outdated
@@ -374,14 +394,14 @@ export default class Locale { | |||
this.eraCache = {}; | |||
|
|||
this.specifiedLocale = specifiedLocale; | |||
this.fastNumbersCached = null; | |||
this.fastNumbersCached = supportsFastNumbers(this); | |||
this.isEnglishCached = |
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.
Similarly, I agree we should cache this, but why not cache it inside isEnglish
? That way if isEnglish
is never called, we don't pay the performance penalty
src/impl/locale.js
Outdated
} | ||
intlConfigCache[key] = localeStr; |
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'm having a hard time understanding how this would give such a big speedup. Can you use the benchmarks in the repo to demonstrate this?
src/impl/locale.js
Outdated
@@ -73,7 +81,18 @@ function getCachedWeekInfo(locString) { | |||
return data; | |||
} | |||
|
|||
function parseLocaleString(localeStr) { | |||
const localeStringCache = {}; | |||
function getParsedCachedLocaleString(localeStr) { |
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 can believe that this parsing is slow, but I'd like to see the benchmarks on this too
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.
Sorry for taking so long to review this. I left some comments
…ers and isEnglish calls to improve performance Signed-off-by: nodify-at <21654050+nodify-at@users.noreply.github.com>
@icambron Thanks for your feedback. I took a thorough approach initially to improve the calls, but I've now simplified it to focus on the isEnglish and fastNumbers calls only. I've also cleaned up all other improvements/changes. Could you please review it again? |
… Intl.resolvedOptions cache Signed-off-by: nodify-at <21654050+nodify-at@users.noreply.github.com>
@icambron Here are the initial results from my local environment: DateTime#format in German: 301,824 ops/sec ±0.41% (95 runs sampled) |
@icambron did you get my last changes ? |
I'm starting to lose hope that this PR will ever get merged 😞 |
Just give it some more time! |
Looks good, merged. Thanks for the contribution. I will release this soon. |
Awesome :) Thanks @icambron |
@@ -167,7 +175,7 @@ function supportsFastNumbers(loc) { | |||
loc.numberingSystem === "latn" || | |||
!loc.locale || | |||
loc.locale.startsWith("en") || | |||
new Intl.DateTimeFormat(loc.intl).resolvedOptions().numberingSystem === "latn" | |||
getCachedIntResolvedOptions(loc.locale).numberingSystem === "latn" |
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.
Should this be loc.intl
?
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.
It looks a bit strange, because in my last commit I reverted this change. getCachedIntResolvedOptions function is used only in supportsFastNumbers and isEnglish .
See the code in master: https://github.com/moment/luxon/blob/master/src/impl/locale.js
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.
Ops, I see your pointed code better now, sorry and you're right it should be intl.
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.
Changes
Performance Impact
Tests indicate up to a 10x speed improvement with these enhancements.
Issue Fixed
Fixes #1428