Repository navigation
Conversation
|
@vzaidman / @javache what's the status of this internally these days?
I'd be happy to see this transform turned off but I half recall some specific performance concerns (@tmikov?) |
|
@vzaidman Do you have any progress with an internal experiment? |
|
I found that there was a concern that the bundle size increases with it, but the investigation for that did not continue. I'm not sure who can pick this up in this point. I will summarize my findings and share it with some teams to see if anyone wants to pursue this. |
|
I had AI do a bit of a deep dive on this, running benchmarks on a couple of real phones across a range of different usage patterns. I'd say it's net good news, but does make bundles slightly larger in most cases (smaller JS, but more inlined iterator handling in HBC is bigger than shared babel helpers), and native is much slower at some (uncommon?) patterns, particularly array destructuring from array literals. The wins on object destructuring and object rest look worth it though. https://robhogan.github.io/reports/react-native-58965-destructuring/ |
Explains what Hermes' hidden fast-destructure flag changes, why no runtime gain is expected, its bundle-size effect on four apps (-0.01% to -0.05%) and its compatibility cost, and recommends against adopting it with react/react-native#58965.
|
IMO, if we (React/Meta) are not planning to run full runtime experiments in prod on removing Babel transforms we theoretically don’t need, the default should be to (responsibly, safely) just ship the removal and monitor the result. Even at the risk of slight short term regression, the performance ceiling is higher long term if we bring Hermes as close as we can to user code. As long as Babel is hiding the engine’s capabilities especially from Meta apps, they’re unlikely to get any attention. (But re this PR @retyui - the crash when |
Updated the logic for preserveDestructuring option to default to true if not specified.
|
@javache has imported this pull request. If you are a Meta employee, you can view this in D126038210. |
|
This pull request was successfully merged by @retyui in 73711b3 When will my fix make it into a release? | How to file a pick request? |
|
Thank you @javache |
|
FYI, this caused a slight bundle size increase for us - if there's any ideas for how to claim this back (or ideas for Hermes bytecode efficiency), please share! cc @tmikov |
Attributes the size increase from react/react-native#58965 to Hermes' inline array-destructuring code (per-element done checks, defaults and register copies) using opcode diffs of RNTester and Mattermost, and lists ways Hermes could claim it back. The section is linkable at #bytecode-size.
|
@javache a small bytecode size increase is consistent with what I saw benchmarking Mattermost and Bluesky. It's all in the array destructuring and Hermes' more correct but verbose unwinding of iterators. I had AI add a bit to the report on the increase here (with some thoughts on what would help in Hermes, no idea how reliable that is but none look easy to roll out): https://robhogan.github.io/reports/react-native-58965-destructuring/#bytecode-size Another option is to reintroduce a more targeted version of the Babel transform that lowers the problem patterns but keeps native object destructuring. |
Summary:
The latest Hermes engine work well with destructuring syntax. I decided to checked perf. on
RN 0.88.x+ Samsung S10 and based on the result I don't see the reason to keep transforming destructuring syntax:Changelog:
[GENERAL] [BREAKING] - Turn off
@babel/plugin-transform-destructuringpluginTest Plan:
babel.config.jsto toggleunstable_preserveDestructuring: true/falseClick to view code