-
-
Notifications
You must be signed in to change notification settings - Fork 184
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
fix: perf regression on hot string munging path #286
Conversation
87eec25
to
7ea55c0
Compare
Running a
With a fresh cache, the difference is sometimes much greater, but sometimes smaller, because it's affected by network variations, but with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving with a suggestion you can take or leave.
7ea55c0
to
bd118f8
Compare
This doesn't change any functionality, but it optimizes a few extremely hot code paths for the input typically encountered during a large npm project installation. `String.normalize()` is cached, and trailing-slash removal is done with a single `String.slice()`, rather than multiple slices and `String.length` comparisons. It is extremely rare that any code path is ever hot enough for this kind of thing to be relevant enough to justify this sort of microoptimization, but these two issues resulted in a 25-50% install time increase in some cases, which is fairly dramatic. Fix: npm/cli#3676 PR-URL: #286 Credit: @isaacs Close: #286 Reviewed-by: @wraithgar
bd118f8
to
edb8e9a
Compare
This doesn't change any functionality, but it optimizes a few extremely hot code paths for the input typically encountered during a large npm project installation. `String.normalize()` is cached, and trailing-slash removal is done with a single `String.slice()`, rather than multiple slices and `String.length` comparisons. It is extremely rare that any code path is ever hot enough for this kind of thing to be relevant enough to justify this sort of microoptimization, but these two issues resulted in a 25-50% install time increase in some cases, which is fairly dramatic. Fix: npm/cli#3676 PR-URL: #286 Credit: @isaacs Close: #286 Reviewed-by: @wraithgar
This doesn't change any functionality, but it optimizes a few extremely hot code paths for the input typically encountered during a large npm project installation. `String.normalize()` is cached, and trailing-slash removal is done with a single `String.slice()`, rather than multiple slices and `String.length` comparisons. It is extremely rare that any code path is ever hot enough for this kind of thing to be relevant enough to justify this sort of microoptimization, but these two issues resulted in a 25-50% install time increase in some cases, which is fairly dramatic. Fix: npm/cli#3676 PR-URL: #286 Credit: @isaacs Close: #286 Reviewed-by: @wraithgar
const {hasOwnProperty} = Object.prototype | ||
module.exports = s => { | ||
if (!hasOwnProperty.call(normalizeCache, s)) | ||
normalizeCache[s] = s.normalize('NFKD') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In long-running server-side application scenarios, this can lead to memory leaks here.
This doesn't change any functionality, but it optimizes a few extremely
hot code paths for the input typically encountered during a large npm
project installation.
String.normalize()
is cached, and trailing-slash removal is done witha single
String.slice()
, rather than multiple slices andString.length
comparisons.It is extremely rare that any code path is ever hot enough for this kind
of thing to be relevant enough to justify this sort of
microoptimization, but these two issues resulted in a 40-50% install
time increase in some cases, which is fairly dramatic.
Fix: npm/cli#3676
References