-2
\$\begingroup\$

I've to calculate 50% of tax .
So I approach it using two ways.

1) public static void main(String[] args) { new Double(500) / 100 * 50); }

2) public static void main(String[] args) { new BigDecimal(500).divide(new BigDecimal(100).multiply(new BigDecimal(50))); }

Using first way that's manually calculating percentage.
And using second, methods of BigDecimal.
So which one is performance wise best?

\$\endgroup\$
  • 3
    \$\begingroup\$ You have 2 horses. Race them. \$\endgroup\$ – Mast Apr 29 '19 at 17:03
  • \$\begingroup\$ Which one is better over another I want to know so I can race only one instead both of them. \$\endgroup\$ – Swapnil Apr 29 '19 at 17:06
  • \$\begingroup\$ Why don't you profile both in a test setup and decide afterwards which one to use in production? \$\endgroup\$ – Mast Apr 29 '19 at 17:25
  • \$\begingroup\$ Ok I'll check and apply. \$\endgroup\$ – Swapnil Apr 29 '19 at 17:27
1
\$\begingroup\$

The first one is more performant because you are creating a Double which is a primitive data type.

In the second one, you are creating three BigDecimal objects which are not a primitive and a lot larger containing a lot more functionality.
This is the code of Big Decimal Divide function.

To see all source code

  public BigDecimal divide(BigDecimal divisor) {
    /*
     * Handle zero cases first.
     */
    if (divisor.signum() == 0) {   // x/0
        if (this.signum() == 0)    // 0/0
            throw new ArithmeticException("Division undefined");  // NaN
        throw new ArithmeticException("Division by zero");
    }

    // Calculate preferred scale
    int preferredScale = saturateLong((long) this.scale - divisor.scale);

    if (this.signum() == 0) // 0/y
        return zeroValueOf(preferredScale);
    else {
        /*
         * If the quotient this/divisor has a terminating decimal
         * expansion, the expansion can have no more than
         * (a.precision() + ceil(10*b.precision)/3) digits.
         * Therefore, create a MathContext object with this
         * precision and do a divide with the UNNECESSARY rounding
         * mode.
         */
        MathContext mc = new MathContext( (int)Math.min(this.precision() +
                                                        (long)Math.ceil(10.0*divisor.precision()/3.0),
                                                        Integer.MAX_VALUE),
                                          RoundingMode.UNNECESSARY);
        BigDecimal quotient;
        try {
            quotient = this.divide(divisor, mc);
        } catch (ArithmeticException e) {
            throw new ArithmeticException("Non-terminating decimal expansion; " +
                                          "no exact representable decimal result.");
        }

        int quotientScale = quotient.scale();

        // divide(BigDecimal, mc) tries to adjust the quotient to
        // the desired one by removing trailing zeros; since the
        // exact divide method does not have an explicit digit
        // limit, we can add zeros too.
        if (preferredScale > quotientScale)
            return quotient.setScale(preferredScale, ROUND_UNNECESSARY);

        return quotient;
    }
}
| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ No problemo =) you should still look through the source code of big decimal if you need the functionality do not reinvent the wheel so to speak use it performance is everything most of the time development is more important. \$\endgroup\$ – Adam Sever Apr 29 '19 at 19:07
  • 1
    \$\begingroup\$ double is a primitive. Double is not a primitive. \$\endgroup\$ – 200_success Apr 29 '19 at 19:09
  • 1
    \$\begingroup\$ Either way, please do not answer off-topic questions. This question will likely be closed soon. \$\endgroup\$ – 200_success Apr 29 '19 at 19:12
  • 1
    \$\begingroup\$ @200_success baeldung.com/java-primitives-vs-objects I read it wrong I understand that the object Double is larger than a primitive however BigDecimal has more overhead then Double. \$\endgroup\$ – Adam Sever Apr 29 '19 at 19:13
  • 2
    \$\begingroup\$ The code is purely hypothetical. The first code sample isn't even syntactically correct. And since the numbers are all hard-coded, it can all be replaced by a hard-coded 250. Finally, we have no context for evaluating the code (information about what range or precision is required). \$\endgroup\$ – 200_success Apr 29 '19 at 19:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.