Thanks Adrian. I wonder when we'd be safe to remove those checks altogether.
Regards
Scott
On 15/08/2012, at 6:25 PM, Adrian Crum wrote:
> Understood. I will revert the two methods.
>
> -Adrian
>
> On 8/14/2012 11:48 PM, Scott Gray wrote:
>> Taking getBigDecimal for example, where 99.999% of
Understood. I will revert the two methods.
-Adrian
On 8/14/2012 11:48 PM, Scott Gray wrote:
Taking getBigDecimal for example, where 99.999% of the time the object will
actually be a BigDecimal, we're now throwing a ClassCastException followed by a
cast. I'm not sure how that translates to on
Taking getBigDecimal for example, where 99.999% of the time the object will
actually be a BigDecimal, we're now throwing a ClassCastException followed by a
cast. I'm not sure how that translates to one object type test?
The Double -> BigDecimal and vice-versa for getDouble are old corner cases
The original code had an instanceof and a cast. So, in the case where
instanceof evaluates to true, there will be two object type tests -
instanceof and the cast. The modification guarantees there will be
only one object type test.
I've seen this optimization used elsewhere, but I haven't a
Hi Adrian,
Are you sure those are optimizations? For getBigDecimal and getDouble I think
almost every call would cause the exception to be thrown, is that actually more
efficient than an instanceof check? I know both are expensive but I don't know
which is more so.
Thanks
Scott
On 14/08/201
