On Tue, Apr 2, 2013 at 3:36 PM, Louis Wasserman <lowas...@google.com> wrote:
> I would be deeply suspicious of benchmarks that naive, especially for > benchmarks like this that involve lots of allocation -- you're most likely > benchmarking the GC, not the actual operation. > Sorry, let me clarify: can you test how much GC is happening here, and what proportion of the benchmark time is being taken by GC either way? The difficulty with benchmarking things like this is that the GC behavior of a pure benchmark that does lots of allocation tends to be nothing at all like the GC behavior of that same operation in the middle of a real application doing lots of other things. I'd be perfectly comfortable with this change justified on the grounds of avoiding unnecessary allocation, but it can be dangerous to make generalizations like "this is X% faster" when a substantial fraction of one run or the other is just the GC running.
