Adam Crockett 🌀

Posted on Apr 5, 2023 • Edited on Apr 11, 2023

console.log is slow

#tip #javascript

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 staggeringly slow.

Edit: kudos DeChamp for this high level reporting although you should run your own tests there are plenty of ideas in the comments, enjoy!

DeChamp • 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

Top comments (51)

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)

Rense Bakker • Apr 8 '23

async/await refers to asynchronous...

Rense Bakker • Apr 8 '23

Ok mate, whatever, go read these articles anyways:
educative.io/answers/are-asynchron...
developer.mozilla.org/en-US/docs/L...

Because what you claimed was dead wrong. Not even any discussion 🤷

Adam Crockett 🌀 • Apr 8 '23

But I haven’t made any claim?

Ian Wright • Apr 8 '23

@lulebe is correct though, wrapping something in a promise doesn't magically make it asynchronous. I believe all Promises also immediately execute, so it won't actually make any difference wrapping it.

Also to be clear the JS event loop in Node is single threaded (unless you use worker threads), it's just part of the internals (C++ I imagine) allows you to process I/O etc in another thread leaving the JS to keep executing.

Rense Bakker • Apr 8 '23

People here are mixing up parallelism and asynchronisity. Recommend everyone read these articles:
educative.io/answers/are-asynchron...
developer.mozilla.org/en-US/docs/L...

And no, @lulebe is not correct. Async does infact make your function asynchronous. It wraps your function in a promise, making it non-blocking, or in other words: the next line of code will execute, without waiting for the result of the previous line. No, it will not make your code execute in another thread.

As for NodeJS... NodeJS itself is multi-threaded, meaning it CAN access multiple cores. It does however execute your javascript code in a single thread, unless you use worker threads yes.

Ian Wright • Apr 8 '23 • Edited

It makes the asynchronous bits inside non-blocking sure (network requests/disk IO). But anything synchronous will still be blocking...

For example run the following, which simulates a slow operation (which is what the article is referring to with the console.log, exaggerated somewhat). There's a significant delay before 3 is logged to the console (tested in JSFiddle).

If however the for loop were replaced with some disk IO instead, then 3 would be logged immediately.

async function two() {
    console.log(2);
  for(let i = 0; i < 10000000000; i++) {}
}

(async function() {
  console.log(1);

  await two();

  console.log(3);
})();

So I still think the comment is correct, that the two function is blocking due to the sync nature of the slow bit. Unless I'm mis-understanding the point you're trying to make?

Adam Crockett 🌀 • Apr 8 '23

Here is a relaxing cat picture to help everyone feel good 😊 I have no further input

Rense Bakker • Apr 8 '23

Yes, the for loop will hang up the thread. async/await is not a method to do parallel execution of code, it doesnt allow you to run multiple threads to do expensive calculations, like doing a for loop one million times. I was purely replying to this claim of yours:

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.

My point was: Yes thats exactly what async does. It wraps whatever you put in it with a promise, making the code non-blocking (asynchronous):

async function two(){
  // await makes this line blocking, within the context of this function
  await new Promise(resolve => {
    // wait for something before resolving
    setTimeout(() => resolve(), 100)
  })
  console.log('finished waiting') // this line didnt block anything
}

console.log('beginning')
two() // returns a promise, doesnt block execution of next line unless you use await
console.log('end')

Rense Bakker • Apr 8 '23

Judging from your examples, what you mean is that the execution of the for loop will keep the main thread busy, making it unable to execute the next line of code. Thats why I tried to clarify that I think there is some confusion about the differences between parallelism and asynchronisity. Nothing in JS except worker threads in NodeJS, will create a new thread, allowing for true parallel execution of code. So when a line of code is keeping the main thread occupied (like when you loop over something a million times), it will freeze up your program. Asynchronous execution of code is a different concept. It just means that not every line of code has to be executed in a chronological order and you can do that in JS with promises or async/await (async just wraps your function in a promise, waiting for the function return, before resolving).

Jan-Stefan Janetzky • Apr 9 '23 • Edited

lol.. this whole thread is bogus..

first of all: Browsers do have multi threaded Javascript.. it is called workers!
node.js had proc forks at first but also moved to workers AFTER Browsers did.
some history there for ye..

secondly: promises (which async / await are) are just a flow abstraction to remove callback hell.
it is just a convenience feature.. syntax sugar...

if you really want true concurrency, use workers or wasm.

Rense Bakker • Apr 9 '23

Yes... But he didn't say concurrency or parallel execution, he said async is not asynchronous, which is still BS.

Ian Wright • Apr 8 '23

Don't take it as we're arguing :) We're trying to understand each other and educate each other if we're incorrect. It's all constructive (at least it seems that way to me, and that's how I'm trying to pitch things).

Adam Crockett 🌀 • Dec 15

No Adam, you are wrong... This is future senior you talking, promise content is still synchronous but it's execution is asynchronous, the actual content of the promise can still be blocking the main thread

yw662 • Apr 11 '23 • Edited

@brense For promises, the execution function will run immediately within the current calling stack.

The promise itself won't run its fulfill callbacks in the same calling stack where it is created even if it is already fulfilled, or fulfilled directly by the executor itself, which is required by the standards. However, that does not mean it won't run the executor in the creation calling stack. It is also required by the standards that the promise runtime should not be lazy or defer the executor.

So, if it is v => new Promise(cb => cb(console.log(v))), it is sync. Console.log will run in the calling stack of the caller.

However, v => Promise.resolve().then(() => console.log(v)) is another story.

So what about async v => console.log(v) ? It is deterministic for sure, which is required by the standards. Why not try it first before you say it ?

Rense Bakker • Apr 12 '23

Not sure what you are replying to specifically. The code examples I gave work as expected. I was merely commenting on the incorrect assumption someone was making that async does not make javascript code asynchronous. Since then we have established they meant to say "concurrent" instead of "asynchronous", which are different things. So if there was a significant performance impact from console.log (which there isnt), using async/promises wont help.

yw662 • Apr 15 '23 • Edited

@brense:
I mean @lulebe is correct technically. The async mark won't magically make a function asynchronous by itself because the promise executor is not deferred. If you mark a sync function as async, it will return a promise so it is thenable, but the execution is not asynchronous/deferred. The promise is fulfilled immediately in the same call stack before all the code lines below the invocation whether it is awaited or not.
It is the fulfillment callbacks to be deferred, but not the executor. To defer the invocation of a sync function (or a promise executor), even if it is marked as async, you need to Promise.resolve().then().

Rense Bakker • Apr 15 '23

No, I know what they meant to say now. They meant to say that async doesnt make code execute in parallel. They're correct about that. The whole discussion that followed, about whether promises/aync will actually allow for asynchronous execution, was pretty much a waste of everyone's time. Obviously it does.

yw662 • Apr 15 '23

No I am saying nothing about being parallel. I am saying execution order.

const f1 = () => console.log(1)
const f2 = () => console.log(2)
const f3 = async() => f1()

(()=> {
  f3()
  f2()
})()

The invocation of f3 is not awaited. However f1 runs before f2.

Rense Bakker • Apr 15 '23

Yes, I'm aware of that, that was never the question...

yw662 • Apr 11 '23

But you are not making console.log async by doing this. Or maybe you can call a setTimeout to make it really happen after everything.

Adam Crockett 🌀 • Apr 12 '23 • Edited

Please forgive the bold text but many have missed even when I clarified this I want to be clear to future readers!

I said async to refer to the concept not async/await I meant what you said, I truly asynchronous function in an asynchronous context

Leander Berg • May 9 '23

Yeah I think saying "async" make me think you mean async/await which is just a fancy syntax for promises, which in turn are really just fancy callbacks, which don't create or use a second thread, but can be used by things like IO which uses a thread pool internally.
Of course promises thereby don't change execution order because how would they without a second thread or randomly reordering your code?

And of course none of us know whether we each have deep knowledge of that, so I just wanted to tell someone looking at this thinking "oh so I can wrap slow stuff in async functions to keep my app snappy" that it doesn't work this way. Sorry for the intense discussion that followed.

MehYam • Apr 8 '23

Hard disagree.

Most logging is synchronous and fast, and you want it to be synchronous for accurate sequencing of instrumentation.

And there's absolutely no harm in mixing async and sync in any language or runtime, you literally can't do anything interactive without it.

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();

DeChamp • 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.

Alvaro Montoro • Apr 5 '23

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

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.

James Vanderpump • Apr 6 '23

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

DeChamp • 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

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

Adam Crockett 🌀 • Apr 8 '23

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

__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.

View full discussion (51 comments)

DEV Community

console.log is slow

Top comments (51)

Read next

How to Enable Communication Between Browser Windows with JavaScript

vueframe a simple Vue 3 component library for embedding video players

JavaScript Object Destructuring

Tracking down high memory usage in Node.js