ben_manes at yahoo.com
Thu Feb 26 23:35:58 UTC 2015
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
If the question is talking about the same post
it seems like the memory usage is something provided by the go runtime
See the -benchmem flag here
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.
More information about the jmh-dev