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

we can get rid of a ton of opcodes, let's do it. make the vm faster #1551

Open
NullVoxPopuli opened this issue Jan 24, 2024 · 1 comment
Open

Comments

@NullVoxPopuli
Copy link
Contributor

NullVoxPopuli commented Jan 24, 2024

With every opcode, we introduce a fair amount of infra to support it.

What if remove the constraint that compiled components must be json?

We embed the compiled json in JavaScript anyway, so why bother with parsing a string as json?

We can emit components as JavaScript objects, use arrows for property access, direct invoke functions, etc.
Reducing all of the opcodes for value rendering. No Vm{Modifier,Primitive,PrimitiveReference,Helper,Property,Variable,DynamicHelper,DynamicModifier,Concat,Constant,etc}

This would probably also greatly simplify the error recovery work, as we'd primarily be deleting code from the vm, and changing what the compiler outputs.

This would then allow us to have a big perf boost at runtime, and allow us to re-do error recovery in a way that doesn't add 80kb and be 20% slower.

(On phone, brevity, etc)

@jelhan
Copy link

jelhan commented Feb 16, 2024

Not sure if I fully understand. A few years back delaying parsing costs to when a component is actually needed was claimed as a performance optimization of Glimmer. Did that changed with current browsers? Or due to code splitting and lazy loading?

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

No branches or pull requests

2 participants