You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
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?
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)
The text was updated successfully, but these errors were encountered: