Is it just me, or does debug log crash unity on large iterations?

So I’m working on a procedural texture generator, and I was trying to get some output from my code to see where one of my math equations was not coming out as intended.
I added a debug line in the iteration, which in turn caused unity to crash. This is not the first time I’ve experience such a thing, and from my experiences, it seems to only occur when you attempt to add a Debug.Log call to an iteration of around or above 1000,000 equations.
I understand that the Debug.Log was never meant to handle over a million entries, but I’d of though Unity would of found a better way of handling the debug log overflow.
So is it just me? Is my computer just so terrible, that it can’t handle the logs? Or does unity really crash every time the log gets overflowed?

Like Glurth alreads said Debug.Log in general is quite slow and shouldn’t called too often. And yes, there’s a “magic limit” at which the performance drops even more drastically. That most likely is related to the fact that each debug log call contains a lot information (log text, context, stacktrace) and the addition to the console is handled in a seperate thread. If you produce too many log entries in a short time span Unity most likely runs out of buffer space and the execution stalls.

The editor usually don’t crash, it just freezes (though that could be for several seconds or even minutes). If you have a case where you constantly adding more logs Unity becomes almost unusable because when another frame is “finished” the entries just stack up. Also keep in mind that holding those log entries in memory can make you easily run out of memory.

Since the datastructures grow and grow in size the more entries there are the more time it takes to allocate / re-allocate those structures which slows it down even further.

Also like Glurth said, it’s usually a good idea if you need to log a lot information to use a StringBuilder and log a single string at the end. The console window limits the text of a single log entry to 64k (that’s a limit of the TextArea). Though the logfile should have the full log entry. Another advantage is that the data is grouped without the stacktrace overhead when you read it in the editor log file and it’s easier to copy and paste blocks of logged data.

StringBuilder sb = new StringBuilder();

for(int i = 0; i < 1000000; i++)
    sb.Append("Some log text #" + i + "

");

Debug.Log("results: 

" +sb.ToString());

The StringBuilder class is located in the System.Text namespace. It’s basically like a “List” of chars which dynamically expand itself to minimize garbage generation. is the line-feed character which makes a new line in a string.

ps: The log overhead is much smaller when you execute the code from a build. Inside the editor the live-feedback in the console is what seems to cause most problems. At runtime the log is not held in memory but directly dumped to the logfile. Though don’t forget to remove those logs when you ship your product. For example the game Creativerse has some chunk generation “bug” and the log file receives thousands / millions of error messages. After playing for a few hours the logfile can grow into hundreds of MB.