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

[Perf] Hoist renderer properties to top-level module #2569

Closed
nolanlawson opened this issue Nov 4, 2021 · 3 comments · Fixed by #2598
Closed

[Perf] Hoist renderer properties to top-level module #2569

nolanlawson opened this issue Nov 4, 2021 · 3 comments · Fixed by #2598

Comments

@nolanlawson
Copy link
Collaborator

nolanlawson commented Nov 4, 2021

Instead of exposing renderer.ts as an object, all of its properties could be exported at the top level of a module. There is only one renderer in the built JS files for @lwc/engine-dom and @lwc/engine-server, so it's effectively a singleton.

Benefits:

  • Smaller code size
  • Avoid future regressions as described in perf: optimize isHydrating #2562
  • No need to attach the renderer object to the VM or look it up
  • The minifier can do dead-code elimination for e.g. if (renderer.ssr) {}, which is always false in @lwc/engine-dom

In a quick proof-of-concept (0003d50), this reduced the Brotli-compressed size of iife/es2017/engine-dom.min.js from 14.8 kB to 14.3 kB (-0.5kB). Plus it shows a decent improvement across the benchmarks, especially for server rendering:

Screen Shot 2021-11-03 at 5 22 37 PM

The tricky part is just figuring out how to structure the code and get the TypeScript types right. The PoC uses a dummy @lwc/engine-impl package, plus a Rollup plugin to replace it at build time, but maybe there's a cleaner way.

@caridy
Copy link
Contributor

caridy commented Nov 8, 2021

If I understand this proposal, you're saying that having all the DOM operations to be in its own package, where each implementation (dom) or (ssr) will be importing different versions of those packages? Can you elaborate more? the POC was too big to get a simple idea.

@nolanlawson
Copy link
Collaborator Author

@caridy Yes, here is the basic idea:

// @lwc/engine-core/some-file.ts
import { createElement } from '__lwc-renderer__'; 

// @lwc/engine-dom/renderer.ts
export { createElement };

// @lwc/engine-server/renderer.ts
export { createElement };

In the above example, Rollup would be responsible for substituting __lwc-renderer__ at build-time with either the engine-dom renderer or the engine-server renderer.

This way, in the built JS file, there is no actual renderer object. There is just a bunch of constants (strings, booleans, functions) at the top level.

@pmdartus
Copy link
Member

pmdartus commented Nov 9, 2021

I am wondering if the added build and typing complexity is worth the 1% runtime performance boost.
That said it is quite interesting that the SSR benchmarks benefit more than the other benchmarks.

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

Successfully merging a pull request may close this issue.

3 participants