A benchmark to check for high-frequency alloc

[jeffallen]

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.

[jeffallen]

Take a look at my recent thread on golang-nuts. It's a pretty deep and interesting problem.

[felixge]

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 :+1:, but so far the GC doesn't seem to cause flight problems or did you end up observing any?

[jeffallen]

The thread is here: https://groups.google.com/forum/#!searchin/golang-nuts/Write$20allocates/golang-nuts/0hfeLJP1LSk/u5QfV6cDIsoJ

I have not seen a problem from GC, but as I mention in the thread, it makes sense to check that the high frequency code path does not alloc. I was pretty sure it didn't, when I found out that it did, I got really interested in why.

-jeff

On Mon, Dec 15, 2014 at 10:34 AM, Felix Geisendörfer < notifications@github.com> wrote:

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 [image: :+1:], but so far the GC doesn't seem to cause flight problems or did you end up observing any?

— Reply to this email directly or view it on GitHub https://github.com/felixge/godrone/pull/56#issuecomment-66968779.

[felixge]

Very interesting, thanks for sharing!