Allocations profiler

[Ben Manes]

I was suggesting it as an example of a different use-case for benchmarking, where the ops/ns would be of less interest when an allocation profiler is enabled. In the JDK case, I think its acceptable to explain that an allocation profiler will give an unusable ops metric, which can be correctly obtained by not using that profiler and is already understood when using profiler suites. I think low-level allocation metrics would have value over attaching a standard profiler, but I guess that's a minority opinion. 

     On Thursday, February 26, 2015 11:57 AM, Matt Warren <matt.warren at live.co.uk> wrote:
   

 >* I am not sure how they are able to pull off low-overhead profiling like
*>* that.*

If the question is talking about the same post
(http://blog.matttproud.com/2014/09/go-testing-patterns-benchmark-setup-and.html),
it seems like the memory usage is something provided by the go runtime
itself.

See the -benchmem flag here
https://golang.org/cmd/go/#hdr-Description_of_testing_flags.

So I don't think it comes from a 3rd party profiler, but instead the
runtime itself. So I guess there's still some overhead, but it's
minimal as the go GC must have knowledge of allocations.

Cheers

Matt