runtime: memoize vendored-package resolution in resolveSpec - #796
Open
pullfrog[bot] wants to merge 1 commit into
Open
runtime: memoize vendored-package resolution in resolveSpec#796pullfrog[bot] wants to merge 1 commit into
pullfrog[bot] wants to merge 1 commit into
Conversation
resolveSpec resolved every @oxc-project/runtime helper specifier through __require.resolve on each import site. That require has a nub-internal parent, so it re-entered the registered resolve hook and paid a createRequire plus a nested hook round trip per call. Transpiled decorator output emits three helper imports per decorated file, so the cost landed on every file of a decorator-heavy tree. Cache the resolved URL per specifier; a vendored package lives in nub's own distribution and cannot move under a running process.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #795.
resolveSpecstep 2 resolved every@oxc-project/runtimehelper specifier through__require.resolveon each import site.__requirehas a nub-internal parent, so each call re-enters the registered resolve hook, takes theisNubInternalParentbranch, and pays acreateRequireplus a nested hook round trip. There are only a handful of distinct helper specifiers, but one import site per decorated file.Transpiled decorator output emits three helper imports (
decorate/decorateMetadata/decorateParam) per decorated file, so this landed on every file of a NestJS-shaped tree.Measured
Generated fixtures, published
nub0.7.5, Node 24.18, Linux x64. Cost tracks the number of helper import sites per file, ~18 ms each:emitDecoratorMetadataEnd to end, with the change:
A CPU profile of the 100-file decorated run attributes 92.4% of wall time to
resolveSpec, of which 31.9% iscreateRequireand 21.8%pathToFileURL— all inside the re-entrant resolve this change removes.Correctness
The cache key is the specifier and the value is a resolved URL. A vendored package lives in nub's own distribution, so its location cannot change under a running process. The
Mapis module-scoped, so each realm (main thread, worker, async-tier loader worker) carries its own — same as the existingresolvingInternalflag.Verified decorator semantics are unchanged with the patch applied: class, method and parameter decorators all fire in order,
design:paramtypesmetadata is emitted correctly, and the decorated class behaves the same.No test added. This is perf-shaped — a timing assertion would be flaky on shared runners, and the observable behavior (resolution result) is already covered.
Note: the second half of #795,
nub --watchreplaying full startup on every edit, is a separate issue and is not addressed here.Claude Opus｜ 𝕏