-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\$

closed as off-topic by 200_success, Toby Speight, pacmaninbw, Sᴀᴍ Onᴇᴌᴀ, Stephen Rauch Apr 30 at 3:07

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – 200_success, Toby Speight, pacmaninbw, Sᴀᴍ Onᴇᴌᴀ, Stephen Rauch
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    \$\begingroup\$ You have 2 horses. Race them. \$\endgroup\$ – Mast Apr 29 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 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 at 17:25
  • \$\begingroup\$ Ok I'll check and apply. \$\endgroup\$ – Swapnil Apr 29 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;
    }
}
\$\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 at 19:07
  • 1
    \$\begingroup\$ double is a primitive. Double is not a primitive. \$\endgroup\$ – 200_success Apr 29 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 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 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 at 19:16

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