Deferred Module Evaluation

TC39 January 2021,

Yulia Startsev

🇨🇦

“As performant as possible

under the circumstances”

What are the circumstances?

• We are looking at a large, mature codebases, where a large part of the cost is module evaluation.
• Alternatively: retain their original behaviour.
• There is a need to make things more performant without making them async.
• Users are ok sacrificing some performance for ergonomics and sync behaviour.

Is this a meaningful await?

Is there an alternative?

Maybe!

Goal:

Improve startup performance without sacrificing readability.

Goal:

Improve startup performance without sacrificing readability.

Goal:

Improve startup performance without sacrificing readability.

Deferring the module...

• Before Load
• Before Parse
• Before Evaluate

Deferring the module...

​

• Before Load
• Before Parse
• Before Evaluate

Deferring the module...

​

• Before Load
• Before Parse
• Before Evaluate

Deferring the module...

​

• Before Load
• Before Parse
• Before Evaluate

This.

Proposed API

alternatively...

Proposed API

alternatively...

Ignore this for now.

Proposed Semantics

• Load and parse all of the modules.
• Children of a deferred module are treated as part of the “deferred graph”
• If a child is eagerly loaded elsewhere, it participates in the deferred module graph as a loaded module.
• Only evaluate the module at first use

Simplified module graph

Left side of parent module is marked as lazy

{ lazyInit: true }

This creates a lazy subgraph, with eagerly loaded modules

Invariant of children finishing evaluation before parents remains.

“Lazy” module graph

Also applies to overlapping lazy/eager graphs

Still eager

This is consistent recursively. Green here is a lazy subgraph of a lazy graph

Known Issues

Top Level Await

Throw?

Top Level Await

Throw?

Alternative: Async is treated eagerly

async module

Side-effectful Get on Local Names

As Global Getter

Problem...

I/O costs - is this really a benefit

• SSD vs HDD
• Network vs local disk
• Real world applications are doing lazy loading of applications, so there is some benefit.

Existing practice in frontend frameworks (link)

Code-splitting:

an important complementary tool

But… what about Suspense? (In repo)

Frontend code, Suspense, cont. (link)

Usability in client-side code

• Two techniques which may make this realistic:
• Resource bundles
• HTTP/3 (or HTTP/2)
• There is strong support for similar proposals, such as import maps
• This could be a supporting proposal for a future story for imports client side.

Summary

• Goal: Improve startup performance without sacrificing readability.
• Solves the motivation through deferring evaluation of modules.
• Requires further investigation regarding expected performance improvements.
• Is a distinct use-case from dynamic import, but both are useful.
• We need to address side-effectful code.

Requesting Stage 1 for

• Investigating deferring module evaluation as a strategy for improving performance at startup.
• With the API (pending further investigation) roughly defined as:

​

​

• To be investigated in stage 1:
• Verifying performance benefit
• Best syntactic approach & solutions to the known issues
• Other constraints raised by committee

Stage 1?

Question: How much startup time do we save?

Firefox Performance characteristics, ~45% spent loading/parsing (on SSD)

Firefox Performance characteristics ~54% spent running

Star configuration at time of profile

Question: Is “laziness” a feature of the edge or the node?

Shared lazy sub-graph, with module-edge level laziness

{ lazyInit: true }

What about a module that should always be lazy?

Marking a module as lazy within the module text (ie. a directive)

“use deferred-eval”

“use deferred-eval”

Shared lazy sub-graph, with module level laziness

“use deferred-eval”

Question: Can we do this with existing code? (link)

Question: Side-effects.

Side-effectful Get on Local Names

Throw?

Side-effectful Get on Local Names (link)

Stage 1?