-
-
Notifications
You must be signed in to change notification settings - Fork 680
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(logger): cache ColorEnabled value #4006
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4006 +/- ##
========================================
Coverage 91.32% 91.32%
========================================
Files 168 168
Lines 10687 10689 +2
Branches 3021 3174 +153
========================================
+ Hits 9760 9762 +2
Misses 926 926
Partials 1 1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
@@ -13,7 +13,8 @@ enum LogPrefix { | |||
} | |||
|
|||
const humanize = (times: string[]) => { | |||
const [delimiter, separator] = [',', '.'] |
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.
These lines should not be changed.
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.
this change doesn't align with the minor tweak mentioned in the title.
I believe modern JS engines will likely inline it after a few iterations anyway. That said, it still introduces unnecessary runtime overhead.
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.
It might be better to use a different PR, but I think it would be better to do the following because there is a lot of waste in the current humanize()
and time()
.
/**
* Humanize the time.
* @param {number} time - The time to humanize.
* @returns {string} The humanized time.
*
* @example
* ```ts
* humanize(1000) // => 1,000
* ```
*/
const humanize = (time: number): string =>
time < 1000 ? String(time) : String(time).replace(/(\d)(?=(\d\d\d)+(?!\d))/g, '$1,')
const time = (start: number): string => {
const delta = Date.now() - start
return delta < 1000 ? `${delta}ms` : `${humanize(Math.round(delta / 1000))}s`
}
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.
Or rather, humanize()
only does its job when the request is over 1000 seconds long, but since there are no such long requests normally, I feel that humanize()
itself is unnecessary.
status: number = 0, | ||
elapsed?: string | ||
) { | ||
const out = | ||
prefix === LogPrefix.Incoming | ||
? `${prefix} ${method} ${path}` | ||
: `${prefix} ${method} ${path} ${colorStatus(status)} ${elapsed}` | ||
: `${prefix} ${method} ${path} ${colorStatus(status, colorEnabled)} ${elapsed}` |
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.
I like the following implementation. This is because the colorStatus
argument can be left as one. I think it's better not to have the colorEnabled
argument here.
diff --git a/src/middleware/logger/index.ts b/src/middleware/logger/index.ts
index 5bb45383..a358e4c5 100644
--- a/src/middleware/logger/index.ts
+++ b/src/middleware/logger/index.ts
@@ -26,18 +26,15 @@ const time = (start: number) => {
}
const colorStatus = (status: number) => {
- const colorEnabled = getColorEnabled()
- if (colorEnabled) {
- switch ((status / 100) | 0) {
- case 5: // red = error
- return `\x1b[31m${status}\x1b[0m`
- case 4: // yellow = warning
- return `\x1b[33m${status}\x1b[0m`
- case 3: // cyan = redirect
- return `\x1b[36m${status}\x1b[0m`
- case 2: // green = success
- return `\x1b[32m${status}\x1b[0m`
- }
+ switch ((status / 100) | 0) {
+ case 5: // red = error
+ return `\x1b[31m${status}\x1b[0m`
+ case 4: // yellow = warning
+ return `\x1b[33m${status}\x1b[0m`
+ case 3: // cyan = redirect
+ return `\x1b[36m${status}\x1b[0m`
+ case 2: // green = success
+ return `\x1b[32m${status}\x1b[0m`
}
// Fallback to unsupported status code.
// E.g.) Bun and Deno supports new Response with 101, but Node.js does not.
@@ -52,13 +49,14 @@ function log(
prefix: string,
method: string,
path: string,
+ colorEnabled: boolean,
status: number = 0,
elapsed?: string
) {
const out =
prefix === LogPrefix.Incoming
? `${prefix} ${method} ${path}`
- : `${prefix} ${method} ${path} ${colorStatus(status)} ${elapsed}`
+ : `${prefix} ${method} ${path} ${colorEnabled ? colorStatus(status) : status} ${elapsed}`
fn(out)
}
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.
@usualoma, What do you think of this implementation?
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.
${colorEnabled ? colorStatus(status) : status}
That's good, I was just thinking the same thing!
Maybe no need to check it in loop ?
Just check one