Explain why my two benchmarks are performing differently than I expect?

[David Karr]

On Mon, Oct 1, 2018 at 1:11 PM Aleksey Shipilev <shade at redhat.com> wrote:

> On 10/01/2018 08:42 PM, David Karr wrote:
> > I recently noticed some code in the codebase I work that looks like this
> > (not with a hardcoded value):
> >
> >         DecimalFormat df = new DecimalFormat("##0.00");
> >         new BigDecimal(df.format(47.0));
> >
> > I was pretty sure that was an inefficient way to do this, which I thought
> > should be more like:
> >
> >         new BigDecimal(47.0).setScale(2, BigDecimal.ROUND_HALF_UP);
>
> ...
>
> > I'd appreciate any help understanding why this is behaving oppositely of
> > what I would expect.
>
> I think you need to start from JMH Samples:
>
> http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/main/java/org/openjdk/jmh/samples/
>
> Notably JMHSample_08_DeadCode and JMHSample_35_Profilers.
>

Thanks.  The deadcode pointer was critical.  What was curious is that the
original benchmark method was just newing up a single BigDecimal, even
though it wasn't doing anything with it, and I think it's likely that
result was accurate.  When I added multiple news of BigDecimal, still not
doing anything with them, that's apparently when the optimizer was
apparently dropping the dead code.  I tried a couple of variations of this,
all returning the values being produced, so I'm reasonably confident the
optimizer wasn't pruning anything.  The stack profiler showed it calling
the constructor, so it wasn't pruning it.

>
> -Aleksey
>
>
>