我有一个Java应用程序,它使用compareTo()
类的BigDecimal
方法,根据类型对(大)实数进行分类,读取为字符串(基本上,&# 34;太大",双重或浮动)。应用程序每秒读取大量此类字符串,因此任何性能优化都是必不可少的。
以下是代码的缩写摘录:
static final BigDecimal MAX_LONG = new BigDecimal(Long.MAX_VALUE);
static final BigDecimal MAX_FLOAT = new BigDecimal(Float.MAX_VALUE);
static final BigDecimal MAX_DOUBLE = new BigDecimal(Double.MAX_VALUE);
String value = readValue(); // Read the number as a string
BigDecimal number = new BigDecimal(value);
if (number.compareTo(MAX_DOUBLE) > 0)
{
...
}
else if (number.compareTo(MAX_FLOAT) > 0)
{
...
}
else if (number.compareTo(MAX_LONG) > 0)
{
...
}
所以,2个问题
答案 0 :(得分:5)
由于BigDecimal是不可变的,因此它也是线程安全的。
您还应该始终使用BigDecimal.valueOf()
而不是new BigDecimal()
,以利用可能的任何缓存。
答案 1 :(得分:1)
我同意那些质疑比较是否确实是瓶颈的人。文件或网络IO时间更有可能。
如果比较确实是一个瓶颈并且您对数据进行了IID或类似的假设,那么如果您保留直方图来计算每个间隔中的输入并且在运行中重新排序测试,那么您将需要更少的比较,以便最常见的情况首先得到验证。
例如,如果有多个数字大于MAX_DOUBLE
,那么您当前的比较阶梯最好。每个数字只需要一次比较。但是,如果大多数数字小于或等于MAX_FLOAT
,则最差,因为那时需要对每个数字进行三次比较。