Description
Current FloatingDecimal implementation contains serious scalability issue ("static synchronized" method), that was fixed. A lot of other improvement also were done.
I have to note that I do not change existing algorithm, I only tuned existing.
Performance result:
1. double -> String
I've separated 3 paths here: using long conversion, "fast path iterative" and "slow path iterative" (slow path uses big arithmetic). Paths have different performance (for example long conversion is 20x times faster than "slow path iterative"), that is why I measured results separately for each path.
- long conversion - +40% boost on SPARC (+30% in x86)
- "fast path iterative" - +10%
- "slow path iterative" (single threaded) - +80%
- "slow path iterative" (multi threaded) - up to 6.5x times faster (on SPARC with 64 hw threads) due to solving scalability problem.
2. Decimal string -> double
- "fast path" - +10%
- "slow path" (single threaded) - +60% on SPARC (+50% on x86)
- "slow path" (multi threaded) - up to 20x times faster (on SPARC with 64 hw threads) due to solving scalability problem.
3. Hex string -> double
- "fast path" (single threaded) - 3x times faster
- "fast path" (multi threaded) - up to 15x times (scalability)
- "slow path" (single threaded) - 5x times
- "slow path" (multi threaded) - up to 27x times (scalability)
4. Modification java.text.DigitList.
(avoid reparsing string obtained from double into digits and exponent) - +15%-%30 (to performance of NumberFormat for double)
I have to note that I do not change existing algorithm, I only tuned existing.
Performance result:
1. double -> String
I've separated 3 paths here: using long conversion, "fast path iterative" and "slow path iterative" (slow path uses big arithmetic). Paths have different performance (for example long conversion is 20x times faster than "slow path iterative"), that is why I measured results separately for each path.
- long conversion - +40% boost on SPARC (+30% in x86)
- "fast path iterative" - +10%
- "slow path iterative" (single threaded) - +80%
- "slow path iterative" (multi threaded) - up to 6.5x times faster (on SPARC with 64 hw threads) due to solving scalability problem.
2. Decimal string -> double
- "fast path" - +10%
- "slow path" (single threaded) - +60% on SPARC (+50% on x86)
- "slow path" (multi threaded) - up to 20x times faster (on SPARC with 64 hw threads) due to solving scalability problem.
3. Hex string -> double
- "fast path" (single threaded) - 3x times faster
- "fast path" (multi threaded) - up to 15x times (scalability)
- "slow path" (single threaded) - 5x times
- "slow path" (multi threaded) - up to 27x times (scalability)
4. Modification java.text.DigitList.
(avoid reparsing string obtained from double into digits and exponent) - +15%-%30 (to performance of NumberFormat for double)
Attachments
Issue Links
- duplicates
-
JDK-5057835 FormattedFloatingDecimal: massive code duplication in J2SE
- Closed
-
JDK-8047346 low performance of java.lang.Double.parseDouble() in highly concurrent envir.
- Resolved
- relates to
-
JDK-4396272 Parsing doubles fails to follow IEEE for largest decimal that should yield 0
- Resolved
-
JDK-8016117 Add the missing new sun.misc.FDBigInteger class
- Closed
-
JDK-5057835 FormattedFloatingDecimal: massive code duplication in J2SE
- Closed
-
JDK-7192954 Fix Float.parseFloat to round correctly and preserve monotonicity.
- Closed
(1 relates to)