koobas.hobune.stream
Why does BinaryWriter allocate memory when writing floats?
I'm writing a quick save/load system, so you can basically tap "F5" and we use a MemoryStream/BinaryWriter combo to write out the game's state. I'm reusing a single byte[] array as a buffer, in an attempt to not do a bunch of allocation every time a save occurs.
This all works great, but I'm seeing a lot of "GC.Alloc" rows appearing in the profiler. Upon further inspection, I found that there is one "GC.Alloc" call per call to BinaryWriter.Write(float), and each of these calls allocates 36B of memory. Floats are fairly common, so this ends up adding up quite a bit, to ultimately 152KB of memory allocation!
Upon further inspection, it's possible for me to pack the float value into a "uint" (since they are both 4 bytes), and I no longer get that 36B allocation.
writer.Write(myFloat); // allocates 36B
writer.Write(ByteUtil.FloatToUInt(myFloat)); // allocates 0B
I guess ultimately my question is this: is it expected that BinaryWriter.Write(float) would allocate memory like this? Is it expected behavior, or is this a bug? Is there any way to know whether this is something that should be reported as a bug to Unity?
(Note: sorry for the horizontal rules, but this site is not properly formatting my paragraphs for some reason...)
That's an interesting and rather unexpected observation. However it seems that Mono simply implemented the Write method this way for floats. Note that the mono version uses the "BitConverterLE.GetBytes" method which returns a new 4 byte array. The code in the "else" section is the code used by the .NET framework.
I don't know that ByteUtil class you're using. However one reason why they might use the BitConverterLE is to ensure little endian byte order. The BinaryWriter always uses little endian byte order to ensure compatibility with other systems. Otherwise when you store some value on a little endian system and read it on a big endian system, the values would come out the wrong way. So you have to ensure you use the same format everytime.
Just to be clear: This is not a bug as nowhere is it mentioned that the Write method doesn't generate garbage. It's just an unfortunate implementation You can roll your own extension methods for the BinaryWriter / Reader, just make sure the endianness is taken care of.
Oh interesting - I didn't realize the source for these functions were available, I'll have to bookmark those links. VS assembly browser just showed empty functions.
When you compile and run Unity code with IL2CPP, is it always using the "#if $$anonymous$$ONO" versions of functions, as far as you're aware? Unity has several player options, and I'm currently using .NET 4.x Equivalent, IL2CPP, .NET Standard 2.0.
The source for the ByteUtil is doing basically what the .NET source is doing. I'll keep an eye out for any endian issues that might arise! Thanks for the info.
