8000 perf(interpolator): use object deconstruction by VIKTORVAV99 · Pull Request #2181 · i18next/i18next · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

perf(interpolator): use object deconstruction #2181

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

Merged
merged 2 commits into from
May 10, 2024

Conversation

VIKTORVAV99
Copy link
Contributor
@VIKTORVAV99 VIKTORVAV99 commented May 10, 2024

The code used in this file can benefit from the use of object deconstruction and optional chaining. Both of these reduce the amount of property lookups the engine needs to do which should help improve performance. Perhaps more important it cuts out unneeded code and allows for better mangling by rollup, cutting down the size of the minified files a bit, without impacting functionality.

Checklist

  • only relevant code is changed (make a diff before you submit the PR)
  • run tests npm run test
  • tests are included
  • commit message and code follows the Developer's Certification of Origin

Checklist (for documentation change)

  • only relevant documentation part is changed (make a diff before you submit the PR)
  • motivation/reason is provided
  • commit message and code follows the Developer's Certification of Origin

@coveralls
Copy link
coveralls commented May 10, 2024

Coverage Status

coverage: 96.313% (+0.02%) from 96.298%
when pulling d8e83fd on VIKTORVAV99:optimize_interpolator.js
into 99d6d69 on i18next:master.

@adrai
Copy link
Member
adrai commented May 10, 2024

We did not use the optional chaining operator etc... because in the past there has been some i18next usage in environments where this was not supported... for example we wanted to still support Node v12 (#1948) and that node version is not able to understand that syntax...
Do you have some tests that proofs that performance is significially better with your change?

@VIKTORVAV99
Copy link
Contributor Author

We did not use the optional chaining operator etc... because in the past there has been some i18next usage in environments where this was not supported... for example we wanted to still support Node v12 (#1948) and that node version is not able to understand that syntax... Do you have some tests that proofs that performance is significially better with your change?

I have not made any performance benchmarking as I was mostly looking to cut down the size of the generated code bundles.

I'd be happy to skip the optional chaining if that means it can be merged quicker (with just the object deconstruction) but is supporting node 12 still something that is required from your side? Node 12 has been out of LTS for almost 4 years soon.

@adrai
Copy link
Member
adrai commented May 10, 2024

is supporting node 12 still something that is required from your side?

not from my side personally, but I'm sure there are some situations in userland that still uses old node versions...

So for now, yes if you remove the optional chaining we can merge that immediately...

@VIKTORVAV99
Copy link
Contributor Author

is supporting node 12 still something that is required from your side?

not from my side personally, but I'm sure there are some situations in userland that still uses old node versions...

So for now, yes if you remove the optional chaining we can merge that immediately...

Will do that then and perhaps open an issue about bumping the minimum node version so it can be discussed?

@adrai
Copy link
Member
adrai commented May 10, 2024

Will do that then and perhaps open an issue about bumping the minimum node version so it can be discussed?

we can do that for the next major version... but I don't think there are a lot of benefits to make a new major version to just drop older node.js versions...

@VIKTORVAV99
Copy link
Contributor Author

Will do that then and perhaps open an issue about bumping the minimum node version so it can be discussed?

we can do that for the next major version... but I don't think there are a lot of benefits to make a new major version to just drop older node.js versions...

Would it be fine if I opened a PR to switch to optional chaining across all of the files then? Then you can merge it whenever you want.

@adrai
Copy link
Member
adrai commented May 10, 2024

Would it be fine if I opened a PR to switch to optional chaining across all of the files then? Then you can merge it whenever you want.

You can, but that will not be merged so soon...

@VIKTORVAV99 VIKTORVAV99 changed the title perf(interpolator): use object deconstruction and optional chaining perf(interpolator): use object deconstruction May 10, 2024
@adrai adrai merged commit d4bc164 into i18next:master May 10, 2024
8 checks passed
@VIKTORVAV99
Copy link
Contributor Author

Would it be fine if I opened a PR to switch to optional chaining across all of the files then? Then you can merge it whenever you want.

You can, but that will not be merged so soon...

That's fine from my side 👍🏻

@VIKTORVAV99 VIKTORVAV99 deleted the optimize_interpolator.js branch May 10, 2024 08:03
@adrai
Copy link
Member
adrai commented May 10, 2024

thank you... it's included in v23.11.4

@VIKTORVAV99 VIKTORVAV99 mentioned this pull request May 10, 2024
7 tasks
heharm pushed a commit to wanderlog/i18next that referenced this pull request Aug 15, 2024
…18next#2181)

* use object deconstruction and optional chaining

* revert optional chaining
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0