console.log improvements

[mertcanaltin]

I viewed this post last week : https://x.com/_rafaelgss/status/1971311652365840717

I want to solve this problem, first look ı read the post by this @RafaelGSS
https://nearform.com/insights/the-cost-of-logging-in-2022/

This post usually mention Pino technics, i will try this technics in node js console area

if your any suggestion pls send comment this issue, thanks all

[BridgeAR]

@mertcanaltin can you please outline what you mean with applying pino technics?

And what problem do you want to fix / what part of console.log do you want to make faster and how? I fail to understand how the mentioned things can be compared to console.log.

[mertcanaltin]

Sure, let me clarify:

I want to optimize console internally with async buffering when output is redirected.

Three optimizations:

1. Async buffer for redirected output
   TTY: sync (unchanged)
   File/pipe: async buffering

2. Non-blocking EAGAIN handling
   Queue messages when descriptor is full
   Retry on next tick instead of blocking

3. stderr always sync, stdout async
   console.error writes immediately (errors never lost)
   console.log uses buffering (performance gain)

Trade-off: Messages immediately before process.exit() may not be written, but critical errors (stderr) are always captured.

Expected impact: Based on Pino benchmarks, async buffering reduces logging overhead by 40-60%. The tweet scenario showed 80% event loop usage from logging - this optimization could address that without removing logs.

I can start with a prototype to demonstrate the performance improvement.

[RafaelGSS]

Considering its interoperability with the front-end side, I'd be very careful with console.log changes. Maybe create a util.log?

[BridgeAR]

All of the mentioned things can not be done in Node.js core.

Console.log has very specific stream behavior (which currently is not ideal, while there is nothing that we really can do changing the sync vs async part).

I am therefore going to close this.

[mertcanaltin]

I get it, thanks for answers

[mertcanaltin]

I'm curious to hear your thoughts on the util.log suggestion @BridgeAR