A benchmark to check for high-frequency alloc #56
Conversation
To see how many allocations happen per pass through the control loop: go test -bench=. We expect that zero allocations happen in the control loop, but in fact 2 happen due to runtime.convertT2I in os.(*File).Write. Discussing with Go maintainers how to fix this. We still need a mock navboard that actually calls os.(*File).Read to check for the same kind of problem there, but a quick read of os/file.go and os/file_unix.go now that I understand the problem makes me think it won't happen on the Read side. Another critical source of garbage to minimize is from the websocket, but that's work for another day.
|
Take a look at my recent thread on golang-nuts. It's a pretty deep and interesting problem. |
A benchmark to check for high-frequency alloc
|
Couldn't find your post on golang-nuts, do you have a link handy? Thanks for working on this. I sort of suspected the runtime to make allocations. Getting these fixed would be great 👍, but so far the GC doesn't seem to cause flight problems or did you end up observing any? |
|
The thread is here: I have not seen a problem from GC, but as I mention in the thread, it makes -jeff On Mon, Dec 15, 2014 at 10:34 AM, Felix Geisendörfer <
|
|
Very interesting, thanks for sharing! |
To see how many allocations happen per pass through
the control loop: go test -bench=.
We expect that zero allocations happen in the control loop,
but in fact 2 happen due to runtime.convertT2I in os.(*File).Write.
Discussing with Go maintainers how to fix this.
We still need a mock navboard that actually calls os.(*File).Read
to check for the same kind of problem there, but a quick read
of os/file.go and os/file_unix.go now that I understand the problem
makes me think it won't happen on the Read side.
Another critical source of garbage to minimize is from the
websocket, but that's work for another day.