我有一个Java应用程序,它使用compareTo()
类的BigDecimal
方法来对一个(大)实数进行分类,根据它的类型(基本上,“太大”、双或浮动)将其读为字符串。应用程序每秒读取大量这样的字符串,因此任何性能优化都是必不可少的。
以下是代码的简略摘录:
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)
{
...
}
所以,有两个问题
发布于 2012-10-29 22:56:39
由于BigDecimal是不可变的,因此它也是线程安全的。
您还应该在整个过程中使用BigDecimal.valueOf()
而不是new BigDecimal()
来利用任何可能的缓存。
发布于 2012-10-29 23:42:41
我同意有人质疑比较是否真的是一个瓶颈。文件或网络IO时间更有可能。
如果比较确实是一个瓶颈,并且您对数据做了一个IID或类似的假设,那么如果您保持一个直方图来统计每个间隔中的输入,并动态地重新排序测试,那么您将需要更少的比较,以便首先验证最常见的情况。
例如,如果有许多比MAX_DOUBLE
更大的数字,那么当前的比较阶梯是最好的。每个数字只需要一个比较。但最糟糕的是,如果大多数数字小于或等于MAX_FLOAT
,那么每个数字需要进行三次比较。
https://stackoverflow.com/questions/13130783
复制相似问题