In my VNC server (where the client picks the endianness), I was trying to use
encoding/binary.Write to write a slice of 921,600 uint16s, 30 times per second.
After being CPU-bound, I looked at a profile and it was dominated by reflect calls.
We've optimized the common cases in encoding/binary, but slices are not optimized at all.
It's also very alloc-heavy, creating a new encoder & scratch space for each Write
I ended up rewriting that part of my code to not use the encoding/binary package and now
it's fast, never stuck in reflect.
The text was updated successfully, but these errors were encountered:
I made a simple patch that does a type assertion if the slice is of basic type. This
gets around reflecting on every element and gives a nice speedup
I made a little benchmark included in the patch which just does a null write with some
BenchmarkWriteSlice1000Int32s 10000 122838 ns/op 32.56 MB/s
BenchmarkWriteSlice1000Int32s 100000 24105 ns/op 165.93 MB/s
I thought i made a CL out of the original patch and it got rejected because it was too
ugly. In hindsight, I concur with that opinion.
Can't find any mail evidence the rejection though, so maybe my memory is faulty. In any
case, i'm releasing this bug so that other people can work on it.