Console.log lazy evaluation make it useless

Developer Tools
#1 
const a={x:1}; 
console.log(a);

a.x=2;
console.log(a)

image

when I’m investigating a big object and want to know where it goes wrong, the console.log is literally useless. I can’t even rely on the value I receive in the console. I can’t find the right value at each point of time. I have to write redundant code conversion to be able log normally. it’s issue with array and objects and it’s really irritating that slow down the debugging tremendously.

I saw there is fixes scheduled for the chrome but didn’t find any thread for firefox. when this can be fixed?

#2

We do have https://bugzilla.mozilla.org/show_bug.cgi?id=1505304 about this.
Unfortunately, this is really not an easy thing to fix, especially considering performance and memory consumption.
We’d need to store all the properties, walking the prototype chain, or choose an arbitrary limit for what we store, which might be also weird.
You can try to log the object wrapping it in a structureClone call (console.log(structuredClone(a))) which will solve the issue

1 Like
#3

thanks, the structuredClone is a good suggestion, but I didn’t get why the performance is a concern in here? assuming the console.log is for debug purposes and it’s a console command and it should behave as it’s intended, I would argue that it’s not a big deal compare to the trouble that currently it’s making for the developers.

#4

we’d have to store a cloned version of the object each time it’s console.log is called. Now imagine a 10000 iteration for loop, logging the window object for example, that would consume quite some memory.
I agree it’s annoying when you stumble upon this, and we could at least make it more explicit, like chrome is doing with their icon saying it was evaluated when the object was expanded

#6

isn’t it too hypothetical? as a best practice usually there shouldn’t be any console.log in production build, but let assume we are bad developers and put console log everywhere.

first assumption is that cloning object use memory but other kind of log doesn’t. but what will happen when we console.log large strings? the console that we are scrolling where it gets its content? doesn’t fall into the same category?

second assumption is that the object that we are cloning is too big, but to be frank a stringified object (if it can be stringified) wouldn’t be more than some kb. let assume it’s 50kb (which is kinda big) each object and 10000 * 50kb is still is 500MB, it’s negligible while default ram you can find on any laptop these days is 8GB

another sad truth is that if you write down 10000 console.log in firefox dev tools it will kill the firefox and freeze it. on frequent basis I need to close the dev tools to free ram and reopen it again. whenever my computer get slow there is a dev tools that is open in some tab.

#7

isn’t it too hypothetical? as a best practice usually there shouldn’t be any console.log in production build, but let assume we are bad developers and put console log everywhere.

console.log shouldn’t have much impact when DevTools are not open, so the concern isn’t here.
But we want people to be able to use DevTools in most situation, and it might happen that you log something in a big loop without thinking too much of it, at least I don’t think this is uncommon.
This is not only about memory, but plain performance: the more objects we need to keep track of, the slower some lookups are going to be.

My concern might be hypothetical for sure, but even if we’d won’t have any perf or memory issue, it doesn’t mean this would be easy; the fact that all vendors DevTools are suffering from this is a good hint that there’s no easy solution.

another sad truth is that if you write down 10000 console.log in firefox dev tools it will kill the firefox and freeze i

Oh, would you have a test case for this? Or even better, maybe you could record a profile of it using the profiler and sharing the result here?

We made significant improvement to console performance in Firefox 101, so I’d be curious where the culprit is here

1 Like
#8

Note to self: this sounds way better than using JSON.