How a single line code change, improved my performance

Quoted from Steve Baker

The thing is that beginners in programming often kinda imagine that the amount of time something takes depends (more or less) on how many lines of code there are executed…which is very much not the case.

On a modern computer, is print statement will usually result in…

1. Calling a library function. Which may have to do things like turning a number into a string of digits in hex or decimal - or into a scientific notation or something…resulting in a new string.
2. The characters in the string being copied into a buffer.
3. The buffered string being passed to some operating system function. Which will find the device driver for the “virtual teletype” device which will pass it on to the windowing system…possibly requiring your program to be paused while the windowing system does it’s work.
4. The windowing system now has to decide whether your text is visible on-screen or hidden behind another window…and whether it causes your window to scroll or something.
5. Then the string has to be turned into graphics commands that are sent to the GPU, which has to turn them into pixels on the screen. The GPU might be busy doing something else - so your graphics commands may be queued up behind other commands… And on and on. Each of those steps could easily be hundreds - maybe even thousands of lines of code.

So - yeah - print statements are very often the slowest thing in your entire program - and in many cases, a single print statement can take more time than the rest of your ENTIRE program.

Worse still - because it MIGHT cause the operating system to stall your entire program - or it MIGHT just append your string into an existing buffer and return - they are wildly unpredictable. Your program might print one character a thousand times - and the first 999 times, the process is relatively fast - and then the 1000th time - your program is stalled for half a second.

source: quora.com/Do-print-statements-in-t...

this one is more optimized, will give you 10-20% faster response.

console.time('abc')
let output = []

for (let i=0;i<=10000000;i++){
    output.push(i)
}

console.log(output.join('\n'))
console.timeEnd('abc')

I know this article is about moving the console.log out of the loop.

But ... 😎

console.time('time');

console.log(Array(1000001).keys().join('\n'));

console.timeEnd('time')

~200ms
Aaaand we are ending up with a whopping 6.9MB of string 🤣

and now you have a memory problem. when working with large data in the real world it's better to work in chunks. so instead of logging everything at once you would build up a buffer/queue then empty the buffer/dequeue at an arbitrary interval usually in a background task.

The problem with big data is it's always there. It doesn't really matter how you restructure the problem it's going to cause headache somewhere.

storing in an array and "printing" every xxxxx numbers seems to work even faster indeed

console.time('time')
let output = []
for (let i=0; i<=1000000; i++){
    output.push(i)
    if (i % 10000 == 0) {
        console.log(output.join('\n'))
        output = []
    }
}
console.log(output.join('\n'))
console.timeEnd('time')

comparing "string build", "array" and "array and flush every xxx"
jsben.ch/rBvkT

Interesting to see such a time difference.

Was this a purely theoretical experiment? Generally, I would only leave console.log in the code for debugging purposes, for which it doesn't matter that much if it's slower. Once everything is working, there usually isn't any reason to log to the console.

Hi, nice article. I tried it and I seems to have better results with this code, which is pretty close to @rc2168st answer :

console.time('time')
let output = []


for (let i=-1;i<=1000000;++i){
    output[i] = i
}

console.log(output.join('\n'))
console.timeEnd('time')

• For me, output[I] = i has always been more improved than output.push(i)
• Same for ++I vs I++ especially in the case of very large loops like here

But in reality it seems to depend on browser :
I made a simple benchmark jsbench.me/38leqsrqbt/2
And my solution seems to be faster in Firefox and Safari, but not in Chrome.

In most languages, signaling something to user by using text or visual interface, is quite heavy operation, because (as mentioned in previous comment) theres a lot of stuff which just have to happen.

In first case, calling console.log is the heavy part, but in second, its printing the string, because its so big.
Try to measure only console.log performance, and log string with different length, You will see the differences aswell.

Also, have a look at performance API, its more precise than console.
developer.mozilla.org/en-US/docs/W...