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: Batch calls to ModuleLoader::prepare_load for dynamic imports #761

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

nathanwhit
Copy link
Member

@nathanwhit nathanwhit commented Jun 3, 2024

Collects dynamic imports between event loop ticks and then calls prepare_load with the collected imports. This reduces the number of calls to prepare_load.
Performance impact on deno is noticeable but relatively modest, around 6-7%:

❯ hyperfine --warmup 10 "deno run -A repro.ts" "devdeno run -A repro.ts"
Benchmark 1: deno run -A repro.ts
  Time (mean ± σ):     211.8 ms ±   2.0 ms    [User: 212.7 ms, System: 85.8 ms]
  Range (min … max):   209.3 ms … 217.4 ms    14 runs

Benchmark 2: devdeno run -A repro.ts
  Time (mean ± σ):     197.3 ms ±   1.2 ms    [User: 189.9 ms, System: 84.5 ms]
  Range (min … max):   195.9 ms … 200.7 ms    14 runs

Summary
  devdeno run -A repro.ts ran
    1.07 ± 0.01 times faster than deno run -A repro.ts

❯ hyperfine --warmup 10 "deno run -A repro2.ts" "devdeno run -A repro2.ts"
Benchmark 1: deno run -A repro2.ts
  Time (mean ± σ):     146.3 ms ±   1.0 ms    [User: 180.9 ms, System: 51.6 ms]
  Range (min … max):   144.5 ms … 148.0 ms    20 runs

Benchmark 2: devdeno run -A repro2.ts
  Time (mean ± σ):     137.8 ms ±   0.8 ms    [User: 160.7 ms, System: 51.7 ms]
  Range (min … max):   136.5 ms … 139.9 ms    21 runs

Summary
  devdeno run -A repro2.ts ran
    1.06 ± 0.01 times faster than deno run -A repro2.ts

My main concern here is the loss of granularity in errors that occur during prepare_load. Since we now are calling prepare_load with multiple specifiers, if the loader returns an error we can't really tell which specifier the error applies to. That results in a visible behavior change for users, for example

await Promise.all([
  import("foo.ts"),
  import("will-cause-prepare-load-error.ts").catch((_e) => {}),
]);

console.log("Done");

Before this PR, that would successfully print "Done", currently with this PR it would throw for the import of "foo.ts" (even though it didn't actually have an error).

@nathanwhit nathanwhit requested review from dsherret and bartlomieju and removed request for dsherret June 3, 2024 21:28
self.pending_dynamic_imports_pending.set(true);
}
Err(err) => {
let exception = to_v8_type_error(scope, err);
self.dynamic_import_reject(scope, dyn_import_id, exception);
for load in dyn_imports {
self.dynamic_import_reject(scope, load.id, exception.clone());
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the part I'm most concerned about, since we just reject all of the import promises in this batch even though the error might only be caused by a subset.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's change the return type of this hook to Vec<Result<(), AnyError>> 👍

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 this pull request may close these issues.

2 participants