[Flight/Fizz] Use Constructors for Large Request/Response Objects in Flight/Fizz #29858
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
React Core Team
acdlite
approved these changes
Jun 11, 2024
github-actions bot
pushed a commit
that referenced
this pull request
Jun 11, 2024
…Flight/Fizz (#29858) We know from Fiber that inline objects with more than 16 properties in V8 turn into dictionaries instead of optimized objects. The trick is to use a constructor instead of an inline object literal. I don't actually know if that's still the case or not. I haven't benchmarked/tested the output. Better safe than sorry. It's unfortunate that this can have a negative effect for Hermes and JSC but it's not as bad as it is for V8 because they don't deopt into dictionaries. The time to construct these objects isn't a concern - the time to access them frequently is. We have to beware the Task objects in Fizz. Those are currently on 16 fields exactly so we shouldn't add anymore ideally. We should ideally have a lint rule against object literals with more than 16 fields on them. It might not help since sometimes the fields are conditional. DiffTrain build for [01a4057](01a4057)
This was referenced Jul 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We know from Fiber that inline objects with more than 16 properties in V8 turn into dictionaries instead of optimized objects. The trick is to use a constructor instead of an inline object literal. I don't actually know if that's still the case or not. I haven't benchmarked/tested the output. Better safe than sorry.
It's unfortunate that this can have a negative effect for Hermes and JSC but it's not as bad as it is for V8 because they don't deopt into dictionaries. The time to construct these objects isn't a concern - the time to access them frequently is.
We have to beware the Task objects in Fizz. Those are currently on 16 fields exactly so we shouldn't add anymore ideally.
We should ideally have a lint rule against object literals with more than 16 fields on them. It might not help since sometimes the fields are conditional.