Skip to content
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

Static Shapes (Hidden Classes) #2813

Closed
HalidOdat opened this issue Apr 13, 2023 · 1 comment
Closed

Static Shapes (Hidden Classes) #2813

HalidOdat opened this issue Apr 13, 2023 · 1 comment
Assignees
Labels
E-Hard Hard difficulty problem execution Issues or PRs related to code execution performance Performance related changes and issues

Comments

@HalidOdat
Copy link
Member

HalidOdat commented Apr 13, 2023

This is a possible optimization to improve Context construction, the biggest bottleneck is builtin initialization and as we add more builtins, the time needed to initialize them will increase, so I thought of the following optimization:

When we initialize builtins we always construct them in the same way, with the same property names and slot index and attributes. In a way the builtin shapes are static, It only changes when the user wants to delete or extend the builtin Object.someNonBuiltInFunction = ....

Why not pre-initialize them at compile time, having a static phf table that contains the shape (its property name and descriptor attributes), and in theory a perfect hash function should be faster, since there are no collisions and also take up less space. This also has the big advantages that it can be shared between builtins from different realms, since it's static it can also be shared across threads.

The only thing that has to be constructed at runtime is the object storage (Vec<JsValue>) which contains the values of the property names. And In the future when we implement #1372 we will be able to eliminate this overhead too :)

And if we want to extend or delete a property, we convert it into a unique shape (copy-on-write) with the changes (as we are already doing by default with all the builtins).

@HalidOdat HalidOdat added performance Performance related changes and issues execution Issues or PRs related to code execution labels Apr 13, 2023
@HalidOdat HalidOdat self-assigned this Apr 13, 2023
@HalidOdat HalidOdat mentioned this issue Apr 23, 2023
28 tasks
@jasonwilliams jasonwilliams added the E-Hard Hard difficulty problem label Jun 7, 2023
@HalidOdat
Copy link
Member Author

Closed per comment #2859 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-Hard Hard difficulty problem execution Issues or PRs related to code execution performance Performance related changes and issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants