I have impression that Debug.log now prints to console much more efficiently.
Is that indeed the case, as the result of general performance improvements of Unity 2020?
Never noticed that it was slow. Do you have examples where it was for you?
@ I am not saying 2019 was slow. But I got impression 2020.1a is much faster. Like profiler produces less spikes, when printing many logs in a frame as example. Which is good thing.
That was soon after I ported project to 2020.1a, with debugging logs enabled.
Unfortunately I donât have anything reliably to compare against atm. So I understand if my words may be just sounding, like blowing in the wind.
It was slow depending on how much youâre printing.
I sometimes have to enable tracing, and in loops the impact can be significant. But, as far as I remember, the bulk of the cost was always related to parsing/processing the actual StackTrace.
I ended up creating a tool that patches Unityâs StackTrace parsing utility because it was too slow.
It also helps that I can cleanup the stack of useless wrappers and stuff, but I did it mostly because of performance.
Theyâve been doing some real work on performance in 2020, so maybe there were improvements, but the StackTrace parsing I donât think received much change lately (I track it, since changes might break my patching).
I think I actually noticed that too, with the profiler. Before, it had a very pronounced spike. Recently, I had a bit of trouble finding the spike to profile my internal logging system.
Of course⌠Whatâs the limit number of characters that Debug.Log can print?
My best guess is that they moved the Console onto the UIElements.
Oh, I mean how frequent youâre printing, but the actual length of the log.
In my tests, most cost was from Unity parsing the StackTrace. Lots of string operations and allocations.
In my case I just print lots of entries, but each individual debug.log is rather short, anything probably between 20-100 characters on average.
Yep, I read about it recently, so that triggered my thoughts on this topic as well.
Doe it means, most UI is now on UIElements? Or you just specifically referring to console?
I am only guessing here, obviously. And I donât think most of it on UIElements. But it is important to note: I may be very wrong either way.
I donât think much of the UI is on UIElements yet.
In the Profiler and in the UIElements debugger you can often see IMGUI containers, so theyâre still using IMGUI in most stuff, like before. Maybe they started with the heavier stuff first.
In particular, they did massive improvements to their TreeViews, so a lot of stuff benefited from that (in particular, the Profiler is now so much faster. Itâs was a huge quality of life improvement).
Just for the fun of it I tried and the answer is 7,250 characters. 
End of off topic. 
Is my only guess, but I suspect, they moved another bit of something into DOTS. Hence improvement. But may be as well UI.
Sorry for striking End of topic
What happens after 7,250? it just cut out, or throws error? Asking, since your âessayâ ends with full stop.
No error message either in Visual Studio or Unity. The original text I had put within the " " was 7,620 characters long and Unity printed 7,250 of them and, yes, itâs funny that it ends just after a full stop.
1 Like
@ I just generated 1000 words of 10 characters each, using
@"
1647460871
8881392224
4945706527
âŚ
8327470407"
Debug.log printed apparently 936 lines (words) = 9360 characters.
Edit:
That actually makes me think, as previously Console allow you to prompt dialog, which you could display full text, in desired format (HEX, ASCII, BIN?). We couldnât print long text before in console. It was trimmed. But was available via that pupup dialog.
I just tried that and Unity printed all the lines! That makes 10,000 characters, why the difference with you? And why the difference with a block of text?
For testing purposes, I added a full new batch of 10,000 random strings of 10 characters to the previous batch, total 2,000 lines of 10 characters and eventually got a â3301â message after printing. Full length: 16,319 characters ( included) in 1,359 lines.
I tried the same with print(ââ) and got the same result. Interesting?
I tried again, this time 2000 lines of 10 strings each
Debug.log ( @"
1706493813
2667790748
...
0649978678
8873<message truncated>
" );
13540
Which gives me 13540 characters, of 1354 words.
In constant
Debug.log ( @"
Z5UaHSm3hj
ET1JKL1gAP
...
LrCdgtdyuq
PzRp<message truncated>
" );
Which gives me 13568 characters, of 1357 words.
For whats more interesting, in my first case scenario of
Each time I run app, number of printed lines slightly vary.
Why are you getting less than me? I did the test with 2020.1.0a9.
I use 2020.1.0a8
Is that a9 vs a8 privilege? 
But honestly I donât know.
The only thing is, I got other things going on at startup as well. Is not just empty project. So maybe that affects somehow? Pure guess. I would need run on empty project to compare. But I donât want to go that far with test of debug log / console for now
The improvement is an effect of the fix for this bug: Unity Issue Tracker - LogStringToConsole is performing too many allocations when printing to console which results in calling GC.collect() often
5 Likes