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
refactor(compiler): use native BigInt when calculating i18n digests #48321
Conversation
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.
Nice cleanup!
aeb4ea1
to
36c110d
Compare
To further modernize and improve the performance of the i18n digest generation, The 64-bit aspects of the process now use the native `BigInt` instead of a custom JavaScript implementation. This removes the need for the big_integer helper code and associated tests as the code was not used anywhere else in the framework. Only the `BigInt` constructor, `BigInt.asUintN` function, and `.toString` function are currently used. `BigInt` literals can unfortunately not yet be used due to the bazel test devmode setup which compiles the TypeScript code at an EcmaScript level that does not yet support the literals. Browser support information: - BigInt constructor: https://caniuse.com/mdn-javascript_builtins_bigint_bigint - BigInt asUintN: https://caniuse.com/mdn-javascript_builtins_bigint_asuintn - BigInt toString: https://caniuse.com/mdn-javascript_builtins_bigint_tostring
36c110d
to
c5ee382
Compare
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.
@clydin this change looks great 👍
This PR was merged into the repository by commit 0f10d75. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
…ngular#48321) To further modernize and improve the performance of the i18n digest generation, The 64-bit aspects of the process now use the native `BigInt` instead of a custom JavaScript implementation. This removes the need for the big_integer helper code and associated tests as the code was not used anywhere else in the framework. Only the `BigInt` constructor, `BigInt.asUintN` function, and `.toString` function are currently used. `BigInt` literals can unfortunately not yet be used due to the bazel test devmode setup which compiles the TypeScript code at an EcmaScript level that does not yet support the literals. Browser support information: - BigInt constructor: https://caniuse.com/mdn-javascript_builtins_bigint_bigint - BigInt asUintN: https://caniuse.com/mdn-javascript_builtins_bigint_asuintn - BigInt toString: https://caniuse.com/mdn-javascript_builtins_bigint_tostring PR Close angular#48321
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
To further modernize and improve the performance of the i18n digest generation, The 64-bit aspects of the process now use the native
BigInt
instead of a custom JavaScript implementation. This removes the need for the big_integer helper code and associated tests as the code was not used anywhere else in the framework. Only theBigInt
constructor,BigInt.asUintN
function, and.toString
function are currently used.BigInt
literals can unfortunately not yet be used due to the bazel test devmode setup which compiles the TypeScript code at an EcmaScript level that does not yet support the literals.This change plus the recent DataView refactoring results in a ~15% performance improvement for digest calculation.
Browser support information (
@angular/compiler
should only be present in an application if using JIT mode):Node.js 10.4.0 and higher also provide support (Angular officially supports
^14.20.0 || ^16.13.0 || ^18.10.0
).Does this PR introduce a breaking change?
Other information