DEV Community

console.log is slow

Adam Crockett 🌀 on April 05, 2023

Im not kidding, your code might not actually be slow, take out your console logs and never benchmark with them inside the code exec, its staggering...

Read full post

Ambuj Singh • Apr 8 '23

The real reason behind this is that console.log is actually synchronous and mixing sync with async is pretty bad in any language or runtime. People should use something like opentelemetry-js or other telemetry tools for logging instead of console.logs.

Adam Crockett 🌀 • Apr 8 '23

Could be but if you move a console.log into an async function theoretically you won’t be blocking and you won’t get the slow down correct? I think there’s more at work here related to the DOM which others have mentioned but equally it might well be this, either way I’m interested in the problem 😊

Leander Berg • Apr 8 '23

Oh no, massive misunderstanding. Async functions do not make anything asynchronous. JavaScript is still single threaded. The only thing they do is making the syntax around using promises or callbacks easier. But a synchronous function like console.log (see, it has no promise) doesn't suddenly turn into an asynchronous one by wrapping it in async. I really suggest you read up on how async/await works because you might be making a lot of mistakes in your code.

Rense Bakker • Apr 8 '23

Whether JavaScript is single threaded depends on the runtime. JS in the browser is single threaded, but NodeJS can be multi threaded. The async keyword does infact mean your function is wrapped in a promise. developer.mozilla.org/en-US/docs/W...

Adam Crockett 🌀 • Apr 8 '23

I’m sorry I’m using slang for asynchronous not referring to async await

Adam Crockett 🌀 • Apr 8 '23 • Edited

Furthermore I’ve been a JavaScript developer for 10 years I understand the call stack and event loop 😭😂 (thanks for the giggle)

Akash Kava • Apr 7 '23 • Edited

Because console in chrome is DOM and every line is a new element, so console.log is roughly equivalent to

let line = document.createElement("div");
for(let item of args) {  
   if (item !== null && typeof item === "object") {
       let segment = document.createElement("span");
       // little carat to open and show element
       segment.class = "drop-down"
       // some sort of expanding object children
       segment.addEventListener("click",
          () => createChildren(item)   });
          // also create some child elements to display few properties... 
          // change class if its an array etc...
          ...
          ...
       continue;
   }
   line.appendChild(document.createTextNode(item.toString()));
}
consoleElement.appendChild(line);
line.scrollIntoView();

Alvaro Montoro • Apr 5 '23

Makes sense. I/O operations are slow (even if it's just output on the screen.)

Petry DeChamp Richardson • Apr 5 '23

Damn sure enough, it's pretty slow.

10000 rows.

with console
422.90000000596046
410.90000000596046
437.30000001192093

without
0.30000001192092896
0.4000000059604645
0.10000002384185791

Sergey S. Volkov • Apr 5 '23

These results was created without opened dev tools tab ?

Adam Crockett 🌀 • Apr 6 '23

thats an interesting question, but if a log is logged in the forrest and nobody is around to see it :) I honestly dont know.

James Vanderpump • Apr 6 '23

Displaying a console.log in a terminal is super slow period.

DimensionCloud • Apr 6 '23 • Edited

Try to reduce the amount of data that is stored in the console.log, also use session store instead of file.
with the definition set as needed here

EXAMPLE:
// Save element position
app.post('/position', (req, res) => {
const positionData = req.body;
const elementId = positionData.elementId;
const sessionData = req.session;

// Update the session data with the new position data for the element
sessionData[elementId] = positionData;

// Return a success status code
res.sendStatus(200);
});

Adam Crockett 🌀 • Apr 6 '23 • Edited

server.log? im refering to JavaScript console.log in both browser and backend environments, particularly in memory and chromium

DimensionCloud • Apr 6 '23

U can also use session store with redis.

DimensionCloud • Apr 6 '23

look on my files how I solved faster response.

Petry DeChamp Richardson • Apr 5 '23

now i'm curious. What numbers did you see?

RYSILVA01 • Apr 6 '23

How did you get it ?
You got me curious. Show us plz

Comment deleted

Robin • Apr 8 '23

This is generated by chatgpt, isn't it?

Adam Crockett 🌀 • Apr 8 '23

No 🙁 I just write on my phone, what makes you say that?

Adam Crockett 🌀 • Apr 8 '23

Oh did you mean the comment sorry I was out of context

__Ciach0 • Apr 9 '23

This is intentional, the Node.js docs say:

A note on process I/O#
process.stdout and process.stderr differ from other Node.js streams in important ways:

They are used internally by console.log() and console.error(), respectively.
Writes may be synchronous depending on what the stream is connected to and whether the system is Windows or POSIX:
Files: synchronous on Windows and POSIX
TTYs (Terminals): asynchronous on Windows, synchronous on POSIX
Pipes (and sockets): synchronous on Windows, asynchronous on POSIX
These behaviors are partly for historical reasons, as changing them would create backward incompatibility, but they are also expected by some users.

Synchronous writes avoid problems such as output written with console.log() or console.error() being unexpectedly interleaved, or not written at all if process.exit() is called before an asynchronous write completes. See process.exit() for more information.

Ian Wright • Apr 8 '23

Might be good to show some examples... stackoverflow.com/a/26754011/21061 gives a nice breakdown with evidence...

Adam Crockett 🌀 • Apr 8 '23

Thanks you’ve all been helpful providing evidence and tests I didn’t expect this post to blow up so much 😮 I see the point about evidence and agree but I just wrote this while making breakfast….