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
Currently every JS-translated assembly content is encoded to a single binary resource which is deserialized in full for both compilation and sitelets runtime.
Multiple approaches for improving compiler and runtime performance is possible:
Separate assembly contents info, expressions, and code dependency graph. Compilation should not need dependency graph of other assemblies, sitelets/rpc runtime should not need expressions, contents info used by both
Deserialize expressions lazily (keep them as "pointers" to a byte array otherwise). Compiler need expressions for inline nodes only, packager+writer need expressions for non-inline nodes only. So a further split is possible
Shrink code dependency graphs using strongly-connected component search. Shrink it further for sitelets runtime where only the resource nodes are relevant targets
The text was updated successfully, but these errors were encountered:
Currently every JS-translated assembly content is encoded to a single binary resource which is deserialized in full for both compilation and sitelets runtime.
Multiple approaches for improving compiler and runtime performance is possible:
The text was updated successfully, but these errors were encountered: