Bug #94442 ResultSetImpl.getDouble is inefficient because of BigDecimal (re)constructions

• Submitted: 22 Feb 2019 10:01
• Modified: 21 Jun 2019 20:51
• Reporter: Oliver Robertshaw
• Status: Closed
• Category: Connector / J
• Severity: S5 (Performance)
• Version: 8.0.15
• OS: Any
• Assigned to: Alexander Soklakov
• CPU Architecture: Any
• Tags: FloatingPointBoundsEnforcer

[22 Feb 2019 10:01] Oliver Robertshaw

Description:
ResultSetImpl.getDouble calls into FloatingPointBoundsEnforcer.createFromBigDecimal, which needlessly recreates BigDecimal objects from the (fixed) min & max bounds. Using a profiler this has been observed to be highly inefficient when reading large numbers of doubles, and a regression vs. connector v.5.

How to repeat:
Call ResultSet.getDouble a lot. Observe performance degredation in v8 compared to v5.

Suggested fix:
Fix FloatingPointBoundsEnforcer to cache the values of BigDecimal.valueOf(min) and BigDecimal.valueOf(max) the first time they are invoked.

These cached values should also be re-used by FloatingPointBoundsEnforcer.createFromBigInteger.

[22 Feb 2019 10:02] Oliver Robertshaw

Profiler

Attachment: yp-profiler.png (image/png, text), 48.29 KiB.

[6 Mar 2019 7:58] Alexander Soklakov

Thanks Oliver! You're right, it should be improved.

[21 Jun 2019 20:51] Daniel So

Posted by developer:
 
Added the following entry to the Connector/J 8.0.17 changelog:

"ResultSetImpl.getDouble() was very inefficient because it called FloatingPointBoundsEnforcer.createFromBigDecimal, which needlessly recreated BigDecimal objects for the fixed minimum and maximum bounds. With this fix, the objects BigDecimal.valueOf(min) and BigDecimal.valueOf(max) are cached after they are first created,thus avoiding their recreations."