3 ms·
Idle curiosity: I wonder if they fixed the 'bug' where if you had a big binary in an error, it got translated to a string representation of a binary, which abso
by davidw 8y ago
Idle curiosity: I wonder if they fixed the 'bug' where if you had a big binary in an error, it got translated to a string representation of a binary, which absolutely blows up memory usage as it works its way through the logger.
In Erlang for instance, you might have a binary like <<"foo">>, which is the 3 bytes, 'f', 'o', 'o'. The display representation of it - <<"foo">> - though, as an Erlang string (which is a linked list of numbers) takes up 18 bytes according to erts_debug:size, which is a huge multiplier.
As always, though, excellent writing by Fred.
- mononcqc 8y agoThis is mostly fixed. First, the loggers tend to use unicode-aware pretty-printing, which lets you have rarer instances of a binary getting blown to its integer bytes representation. Then there's also ways to prevent just printing huge terms out. That's what parameters like `term_depth` in many handlers do (I believe it's just `depth` in the default handlers). They limit how deep you go into outputting some data. So even if you have some very large strings or deeply nested structure, they can get elided when they reach a certain threshold.