logoalt Hacker News

rf15today at 4:20 PM1 replyview on HN

I don't get it. You had to face the problem of a type in a network protocol that had no direct Java equivalent, and decided, for something so low level and performance critical, to create a new instantiable Class? With the expressed intent to not use it for mathematical operations?

So instead of suffering the penalties of

bytes -> BigDecimal (with validation of course)

you thought it's better to add more construction steps in the form of

bytes -> Decimal32 (validation included) -> Big Decimal?

Do you know what kind of performance overhead this entails for your JDBC driver? Because the latter looks roughly about twice as slow, depending on the complexity of your validation code.


Replies

dzaimatoday at 5:17 PM

The type seems to just be a small wrapper around a BigDecimal; the actual conversion arithmetic will presumably be relatively extremely slow regardless, a single extra allocation (in addition to BigDecimal's ≥3) won't change much.

show 1 reply