blocks|key|3338352|text|也许您应该从a=+(1/b)+*c替换为a=+c/b开始？虽然不是10倍，但仍然很不错。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3338353|如果我是你，我会创造我自己的班级资金，它将保留长期美元和长期美分，并在其中进行数学计算。|3338354|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

May be you should start with replacing a = (1/b) * c with a = c/b ? It's not 10x, but still something.

If I were you, I'd create my own class Money, which would keep long dollars and long cents, and do math in it.

blocks|key|3125441|text|店长为数分钱。例如，BigDecimal+money+=+new+BigDecimal+("4.20")变为long+money+=+420。您只需记住mod为100，就可以获得美元和美分的输出。如果你需要追踪，比方说，十分之一美分，它就变成了long+money+=+4200。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3125442|entityMap^0|A|16|1I|G|3E|H|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

Store longs as the number of cents. For example, <code>BigDecimal money = new BigDecimal ("4.20")</code> becomes <code>long money = 420</code>. You just have to remember to mod by 100 to get dollars and cents for output. If you need to track, say, tenths of a cent, it'd become <code>long money = 4200</code> instead.

blocks|key|346417|text|你可能想转到定点数学。现在只是在搜索一些库。在sourceforge+fixed-point上，我还没有深入研究过这个问题。beartonics|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|346418|你用org.jscience.economics.money测试了吗？因为这保证了准确性。固定点将仅与分配给每个片段的位数一样精确，但速度很快。|346419|entityMap|0|LINK|mutability|MUTABLE|url|http://sourceforge.net/projects/jmfp|1|http://www.beartronics.com/imode/fplib/index.html^0|Z|B|0|1Q|A|1|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

You might want to move to fixed point math. Just searching for some libraries right now.
on sourceforge <a href="http://sourceforge.net/projects/jmfp" rel="nofollow noreferrer">fixed-point</a> I haven't looked at this in depth yet. <a href="http://www.beartronics.com/imode/fplib/index.html" rel="nofollow noreferrer">beartonics</a>

Did you test with org.jscience.economics.money? since that has assured accuracy. The fixed point will only be as accurate as the # of bits assigned to each piece, but is fast.

blocks|key|3338467|text|1/b也不能完全用BigDecimal表示。查看API文档，了解如何对结果进行四舍五入。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3338468|基于一两个长字段编写自己的固定十进制类应该不会太难。我不知道任何合适的现成的库。|3338469|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

1/b is not exactly representable with BigDecimal either. See the API docs to work out how the result is rounded.

It shouldn't be too difficult to write your own fixed decimal class based around a long field or two. I don't know any appropriate off the shelf libraries.

blocks|key|346465|text|假设您可以达到某种任意但已知的精度(比方说十亿分之一美分)，并且有一个已知的最大值，您需要处理(一万亿美元？)您可以编写一个类，将该值存储为十亿分之一美分的整数。您需要两个长整型来表示它。这可能比使用double慢10倍，比BigDecimal快100倍。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|346466|大多数操作只是在每个部分上执行操作并重新规范化。除法稍微复杂一点，但不是很多。|346467|编辑:对评论的回应。你需要在你的类上实现一个位移位操作(就像高长的乘法器是2的幂一样简单)。要做除法，将除数移位，直到它不完全大于被除数；从被除数中减去移位的除数，然后递增结果(使用适当的移位)。重复一遍。|346468|再次编辑:你可能会在这里找到你需要的BigInteger。|346469|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Assuming you can work to some arbitrary but known precision (say a billionth of a cent) and have a known maximum value you need handle (a trillion trillion dollars?) you can write a class which stores that value as an integer number of billionths of a cent. You'll need two longs to represent it. That should be maybe ten times as slow as using double; about a hundred times as fast as BigDecimal.

Most of the operations are just performing the operation on each part and renormalizing. Division is slightly more complicated, but not much.

EDIT:In response to the comment. You will need to implement a bitshift operation on your class (easy as along as the multiplier for the high long is a power of two). To do division shift the divisor until it's not quite bigger than the dividend; subtract shifted divisor from dividend and increment the result (with appropriate shift). Repeat.

EDIT AGAIN:You may find BigInteger does what you need here.

blocks|key|351415|text|您使用的是什么版本的JDK/JRE？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|351416|此外，您可以尝试ArciMath+BigDecimal，看看他们是否为您加快了速度。|offset|length|351417|编辑：|351418|我记得在某处读到过(我认为这是有效的Java)，在某个时刻，BigDecmal类从JNI调用到C库变成了所有的Java……从那时起它变得更快了。因此，您使用的任何任意精确库都可能不会给您带来所需的速度。|351419|entityMap|0|LINK|mutability|MUTABLE|url|http://users.belgacombusiness.net/arci/^0|0|8|J|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

What version of the JDK/JRE are you using?

Also you might try <a href="http://users.belgacombusiness.net/arci/" rel="nofollow noreferrer">ArciMath BigDecimal</a> to see if theirs speeds it up for you.

Edit:

I remember reading somewhere (I think it was Effective Java) that the BigDecmal class was changed from being JNI called to a C library to all Java at some point... and it got faster from that. So it could be that any arbitrary precision library you use is not going to get you the speed you need.

blocks|key|346478|text|JNI是一种可能性吗？您可能能够恢复一些速度，并潜在地利用现有的本机定点库(甚至可能还有一些SSE*优点)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|346479|也许是http://gmplib.org/|offset|length|346480|entityMap|0|LINK|mutability|MUTABLE|url|http://gmplib.org/^0|0|3|I|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Is JNI a possibility? You may be able to recover some speed and potentially leverage existing native fixed point libraries (maybe even some SSE* goodness too)

Perhaps <a href="http://gmplib.org/" rel="nofollow noreferrer">http://gmplib.org/</a>

blocks|key|351429|text|就我个人而言，我不认为BigDecimal是理想的解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|351430|你真的想实现你自己的Money类，在内部使用long来表示最小的单位(即，10美分)。在这方面有一些工作，实现add()和divide()等，但这并不是真的那么难。|offset|length|style|CODE|351431|entityMap^0|0|1J|5|1P|8|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]|$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|I|$]]

Personally, I don't think BigDecimal is ideal for this.

You really want to implement your own Money class using longs internally to represent the smallest unit (i.e. cent, 10th cent). There is some work in that, implementing <code>add()</code> and <code>divide()</code> etc, but it's not really that hard.

blocks|key|346508|text|也许你应该考虑获得硬件加速的十进制运算？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|346509|http://speleotrove.com/decimal/|offset|length|346510|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|V|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

Maybe you should look into getting hardware accelerated decimal arithmetics?

<a href="http://speleotrove.com/decimal/" rel="nofollow noreferrer">http://speleotrove.com/decimal/</a>

blocks|key|3125680|text|大多数double操作都会给你足够的精确度。你可以用两倍的精度代表10万亿美元，这对你来说可能已经足够了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3125681|在我工作过的所有交易系统中(四家不同的银行)，他们都使用了双精度，并进行了适当的舍入。我看不出有任何理由要使用BigDecimal。|3125682|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Most double operations give you more than enough precision. You can represent $10 trillion with cent accuracy with double which may be more than enough for you.

In all the trading systems I have worked on (four different banks), they have used double with appropriate rounding. I don't see any reason to be using BigDecimal.

blocks|key|351436|text|关于计算的目的，您能提供更多的见解吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|351437|您要处理的是速度和精度之间的权衡。如果切换到原语，精度损失会有多大？|351438|我认为在某些情况下，用户可能会对较低的精确度来换取速度感到满意，只要他们能够在需要的时候钻研准确的计算。这真的取决于您将使用此计算的用途。|351439|也许你可以允许用户使用doubles快速预览结果，然后如果他们愿意，可以使用BigDecimal请求更精确的值？|351440|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Can you provide more insight as to the purpose of the calculation? 

What your dealing with is a trade-off between speed and precision. How great will the loss in precision be if you switched to a primitive?

I think in some cases the user may be comfortable with less accuracy in exchange for speed, so long as they can hone in on the accurate calculation when needed. It really depends on what you will use this calculation for.

Perhaps you can allow the user to preview the result quickly using doubles, and then request the more precise value using BigDecimal if they wish?

blocks|key|3338624|text|我记得参加了一次来自IBM的关于BigDecimal硬件加速实现的销售演示。因此，如果您的目标平台是IBM+System+z或System+p，则可以无缝地利用这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3338625|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I remember attending a sales presentation from IBM for a hardware accelerated implementation of BigDecimal. So if your target platform is IBM System z, or System p, you could exploit this seamlessly.

blocks|key|346539|text|在99年的股票交易系统中也有类似的问题。在设计之初，我们选择将系统中的每个数字表示为一个长整型乘以1000000，因此1.3423等于1342300L。但主要的驱动因素是内存占用，而不是直线性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|346540|提醒一句，我今天不会再这样做了，除非我真的确定数学表现是超级关键的。在大多数bog标准webapps中，jdbc访问和访问其他网络资源的开销淹没了拥有真正快速数学的任何好处。|346541|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Had a similar problem to this in an equity trading system back in 99. At the very start of the design we choose to have every number in the system represented as a long multiplied by 1000000 thus 1.3423 was 1342300L. But the main driver for this was memory foot print rather than straight line performance.

One word on caution, I wouldn't do this again today unless I was really sure that the math performance was super critical. In most bog standard webapps the overhead of jdbc access and accessing other network resources swamps any benefit of having really quick math.

blocks|key|348797|text|Only+10x+performance+increase+desired+for+something+that+is+1000x+slower+than+primitive?!.|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|348798|在这方面投入更多的硬件可能会更便宜(考虑到货币计算错误的概率)。|unstyled|348799|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|J|8|@]|9|@]|A|$]]|$1|G|3|-4|5|F|7|K|8|@]|9|@]|A|$]]]|H|$]]

<pre><code>Only 10x performance increase desired for something that is 1000x slower than primitive?!.
</code></pre>

Throwing a bit more hardware at this might be cheaper (considering the probability of having a currency calculation error).

blocks|key|346549|text|似乎最简单的解决方案是使用BigInteger而不是long来实现pesto的解决方案。如果它看起来很混乱，那么编写一个包装BigInteger的类来隐藏精度调整是很容易的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|346550|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It seems like the simplest solution is to use BigInteger instead of long to implement pesto's solution. If it seems messy it would be easy to write a class that wraps BigInteger to hide the precision adjustment.

blocks|key|3338739|text|简单..。经常舍入您的结果将消除双精度数据类型的错误。如果你正在进行余额计算，你还必须考虑谁将拥有由于舍入而产生的更多/更少的便士。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3338740|大分贝计算也产生更多/更少的便士，考虑100/3的情况。|3338741|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

easy... round your results often will eliminate double data type's error.
if you are doing balance calculation, you have to also consider who will own the more/less penny caused by rounding. 

bigdeciaml calculation produces more/less penny too, consider 100/3 case.

blocks|key|3338761|text|我知道我是在一个很老的话题下发帖，但这是谷歌找到的第一个话题。考虑将您的计算移动到您可能要从中提取数据进行处理的数据库。我也同意Gareth+Davis的观点，他写道：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3338762|3338763|。在大多数bog标准webapps中，jdbc访问和访问其他网络资源的开销淹没了拥有真正快速数学的任何好处。|blockquote|3338764|3338765|3338766|在大多数情况下，错误的查询对性能的影响比数学库更高。|3338767|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|M|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|N|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Q|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|K|$]]

I know that I'm posting under very old topic, but this was the first topic found by google.
Consider moving your calculations to the database from which you probably are taking the data for processing. Also I agree with Gareth Davis who wrote:

<blockquote>
 . In most bog standard webapps the overhead of jdbc access and accessing other network 
 resources swamps any benefit of having really quick math.
</blockquote>

In most cases wrong queries have higher impact on performance than math library.

blocks|key|351553|text|所以我最初的回答是完全错误的，因为我的基准测试写得很糟糕。我想我才是那个应该被批评的人，而不是OP+;)这可能是我写的第一个基准测试之一……哦，好吧，这就是你学习的方式。这里的结果不是删除答案，而是我没有测量错误的东西。一些注意事项：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|351554|351555|预先计算数组，这样我就不会通过生成它们来扰乱结果|unordered-list-item|351556|永远不要调用BigDecimal.doubleValue()，因为它非常慢|offset|length|style|CODE|351557|不要通过添加BigDecimals来扰乱结果，只返回一个值，并使用if语句来阻止编译器优化。不过，请确保它在大部分时间内都能正常工作，以允许分支预测消除该部分代码。|351558|351559|测试：|351560|Double|351561|BigDecimal:完全按照您的建议计算it|351562|
|351563|BigDecNoRecip：(1/b)+*c=+c/b，只需执行c/b|351564|351565|：使用Double|351566|
执行数学运算|351567|下面是输出：|351568|+0%25+Scenario{vm=java,+trial=0,+benchmark=Double}+0.34+ns;+?=0.00+ns+@+3+trials
33%25+Scenario{vm=java,+trial=0,+benchmark=BigDecimal}+356.03+ns;+?=11.51+ns+@+10+trials
67%25+Scenario{vm=java,+trial=0,+benchmark=BigDecNoRecip}+301.91+ns;+?=14.86+ns+@+10+trials

++++benchmark++++++ns+linear+runtime
+++++++Double+++0.335+=
+++BigDecimal+356.031+==============================
BigDecNoRecip+301.909+=========================

vm:+java
trial:+0|code-block|syntax|javascript|351569|代码如下：|351570|import+java.math.BigDecimal;
import+java.math.MathContext;
import+java.util.Random;

import+com.google.caliper.Runner;
import+com.google.caliper.SimpleBenchmark;

public+class+BigDecimalTest+{
++public+static+class+Benchmark1+extends+SimpleBenchmark+{
++++private+static+int+ARRAY_SIZE+=+131072;

++++private+Random+r;

++++private+BigDecimal[][]+bigValues+=+new+BigDecimal[3][];
++++private+double[][]+doubleValues+=+new+double[3][];

++++@Override
++++protected+void+setUp()+throws+Exception+{
++++++super.setUp();
++++++r+=+new+Random();

++++++for(int+i+=+0;+i+<+3;+i%2B%2B)+{
++++++++bigValues[i]+=+new+BigDecimal[ARRAY_SIZE];
++++++++doubleValues[i]+=+new+double[ARRAY_SIZE];

++++++++for(int+j+=+0;+j+<+ARRAY_SIZE;+j%2B%2B)+{
++++++++++doubleValues[i][j]+=+r.nextDouble()+*+1000000;
++++++++++bigValues[i][j]+=+BigDecimal.valueOf(doubleValues[i][j]);+
++++++++}
++++++}
++++}

++++public+double+timeDouble(int+reps)+{
++++++double+returnValue+=+0;
++++++for+(int+i+=+0;+i+<+reps;+i%2B%2B)+{
++++++++double+a+=+doubleValues[0][reps+&+131071];
++++++++double+b+=+doubleValues[1][reps+&+131071];
++++++++double+c+=+doubleValues[2][reps+&+131071];
++++++++double+division+=+a+*+(1/b)+*+c;+
++++++++if((i+&+255)+==+0)+returnValue+=+division;
++++++}
++++++return+returnValue;
++++}

++++public+BigDecimal+timeBigDecimal(int+reps)+{
++++++BigDecimal+returnValue+=+BigDecimal.ZERO;
++++++for+(int+i+=+0;+i+<+reps;+i%2B%2B)+{
++++++++BigDecimal+a+=+bigValues[0][reps+&+131071];
++++++++BigDecimal+b+=+bigValues[1][reps+&+131071];
++++++++BigDecimal+c+=+bigValues[2][reps+&+131071];
++++++++BigDecimal+division+=+a.multiply(BigDecimal.ONE.divide(b,+MathContext.DECIMAL64).multiply(c));
++++++++if((i+&+255)+==+0)+returnValue+=+division;
++++++}
++++++return+returnValue;
++++}

++++public+BigDecimal+timeBigDecNoRecip(int+reps)+{
++++++BigDecimal+returnValue+=+BigDecimal.ZERO;
++++++for+(int+i+=+0;+i+<+reps;+i%2B%2B)+{
++++++++BigDecimal+a+=+bigValues[0][reps+&+131071];
++++++++BigDecimal+b+=+bigValues[1][reps+&+131071];
++++++++BigDecimal+c+=+bigValues[2][reps+&+131071];
++++++++BigDecimal+division+=+a.multiply(c.divide(b,+MathContext.DECIMAL64));
++++++++if((i+&+255)+==+0)+returnValue+=+division;
++++++}
++++++return+returnValue;
++++}
++}

++public+static+void+main(String...+args)+{
++++Runner.main(Benchmark1.class,+new+String[0]);
++}
}|351571|entityMap^0|0|0|0|6|O|0|6|A|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1I|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1J|8|@$H|1K|I|1L|J|K]]|9|@]|A|$]]|$1|L|3|M|5|E|7|1M|8|@$H|1N|I|1O|J|K]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1R|8|@]|9|@]|A|$]]|$1|S|3|T|5|E|7|1S|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1T|8|@]|9|@]|A|$]]|$1|W|3|X|5|E|7|1U|8|@]|9|@]|A|$]]|$1|Y|3|V|5|6|7|1V|8|@]|9|@]|A|$]]|$1|Z|3|10|5|E|7|1W|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1X|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|15|3|16|5|17|7|1Z|8|@]|9|@]|A|$18|19]]|$1|1A|3|1B|5|6|7|20|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|17|7|21|8|@]|9|@]|A|$18|19]]|$1|1E|3|-4|5|6|7|22|8|@]|9|@]|A|$]]]|1F|$]]

So my original answer was just flat out wrong, because my benchmark was written badly. I guess I'm the one who should have been criticized, not OP ;) This may have been one of the first benchmarks I ever wrote... oh well, that's how you learn. Rather than deleting the answer, here are the results where I'm not measuring the wrong thing. Some notes:

<ul>
<li>Precalculate the arrays so I don't mess with the results by generating them</li>
<li>Don't ever call <code>BigDecimal.doubleValue()</code>, as it's extremely slow</li>
<li>Don't mess with the results by adding <code>BigDecimal</code>s. Just return one value, and use an if statement to prevent compiler optimization. Make sure to have it work most of the time to allow branch prediction to eliminate that part of the code, though.</li>
</ul>

Tests:

<ul>
<li>BigDecimal: do the math exactly as you suggested it</li>
<li>BigDecNoRecip: (1/b) * c = c/b, just do c/b</li>
<li>Double: do the math with doubles</li>
</ul>

Here is the output:

<pre><code> 0% Scenario{vm=java, trial=0, benchmark=Double} 0.34 ns; ?=0.00 ns @ 3 trials
33% Scenario{vm=java, trial=0, benchmark=BigDecimal} 356.03 ns; ?=11.51 ns @ 10 trials
67% Scenario{vm=java, trial=0, benchmark=BigDecNoRecip} 301.91 ns; ?=14.86 ns @ 10 trials

 benchmark ns linear runtime
 Double 0.335 =
 BigDecimal 356.031 ==============================
BigDecNoRecip 301.909 =========================

vm: java
trial: 0
</code></pre>

Here's the code:

<pre><code>import java.math.BigDecimal;
import java.math.MathContext;
import java.util.Random;

import com.google.caliper.Runner;
import com.google.caliper.SimpleBenchmark;

public class BigDecimalTest {
 public static class Benchmark1 extends SimpleBenchmark {
 private static int ARRAY_SIZE = 131072;

 private Random r;

 private BigDecimal[][] bigValues = new BigDecimal[3][];
 private double[][] doubleValues = new double[3][];

 @Override
 protected void setUp() throws Exception {
 super.setUp();
 r = new Random();

 for(int i = 0; i &lt; 3; i++) {
 bigValues[i] = new BigDecimal[ARRAY_SIZE];
 doubleValues[i] = new double[ARRAY_SIZE];

 for(int j = 0; j &lt; ARRAY_SIZE; j++) {
 doubleValues[i][j] = r.nextDouble() * 1000000;
 bigValues[i][j] = BigDecimal.valueOf(doubleValues[i][j]); 
 }
 }
 }

 public double timeDouble(int reps) {
 double returnValue = 0;
 for (int i = 0; i &lt; reps; i++) {
 double a = doubleValues[0][reps &amp; 131071];
 double b = doubleValues[1][reps &amp; 131071];
 double c = doubleValues[2][reps &amp; 131071];
 double division = a * (1/b) * c; 
 if((i &amp; 255) == 0) returnValue = division;
 }
 return returnValue;
 }

 public BigDecimal timeBigDecimal(int reps) {
 BigDecimal returnValue = BigDecimal.ZERO;
 for (int i = 0; i &lt; reps; i++) {
 BigDecimal a = bigValues[0][reps &amp; 131071];
 BigDecimal b = bigValues[1][reps &amp; 131071];
 BigDecimal c = bigValues[2][reps &amp; 131071];
 BigDecimal division = a.multiply(BigDecimal.ONE.divide(b, MathContext.DECIMAL64).multiply(c));
 if((i &amp; 255) == 0) returnValue = division;
 }
 return returnValue;
 }

 public BigDecimal timeBigDecNoRecip(int reps) {
 BigDecimal returnValue = BigDecimal.ZERO;
 for (int i = 0; i &lt; reps; i++) {
 BigDecimal a = bigValues[0][reps &amp; 131071];
 BigDecimal b = bigValues[1][reps &amp; 131071];
 BigDecimal c = bigValues[2][reps &amp; 131071];
 BigDecimal division = a.multiply(c.divide(b, MathContext.DECIMAL64));
 if((i &amp; 255) == 0) returnValue = division;
 }
 return returnValue;
 }
 }

 public static void main(String... args) {
 Runner.main(Benchmark1.class, new String[0]);
 }
}
</code></pre>

blocks|key|3338785|text|Commons+Math+-+Apache+Commons数学库|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3338786|http://mvnrepository.com/artifact/org.apache.commons/commons-math3/3.2|offset|length|3338787|根据我自己针对特定用例的基准测试，它比double慢10+-20倍(比1000倍好得多)--基本上是加法/乘法。在对另一种算法进行基准测试后，该算法具有一系列的加法和一次幂运算，性能下降相当严重:+200x+-+400x。因此，对于%2B和*，它看起来相当快，但对于exp和log却不是。|3338788|Java是一个轻量级的、自包含的数学和统计组件库，用于解决|3338789|编程语言或Commons+Lang中无法解决的最常见问题。|blockquote|3338790|3338791|3338792|注意:+API保护构造函数在命名工厂DfpField+(而不是更直观的DfpFac或DfpFactory)时强制使用工厂模式。所以你必须使用|3338793|new+DfpField(numberOfDigits).newDfp(myNormalNumber)|code-block|syntax|javascript|3338794|要实例化Dfp，您可以调用.multiply或其他方法。我想我应该提到这一点，因为它有点令人困惑。|style|CODE|3338795|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1Y|0|0|0|0|0|0|0|0|0|D|9|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@$D|18|E|19|1|1A]]|A|$]]|$1|F|3|G|5|6|7|1B|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1C|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1D|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1H|8|@]|9|@]|A|$T|U]]|$1|V|3|W|5|6|7|1I|8|@$D|1J|E|1K|X|Y]]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|10|$11|$5|12|13|14|A|$15|C]]]]

Commons Math - The Apache Commons Mathematics Library

<a href="http://mvnrepository.com/artifact/org.apache.commons/commons-math3/3.2" rel="nofollow">http://mvnrepository.com/artifact/org.apache.commons/commons-math3/3.2</a>

According to my own benchmarking for my specific use case it's 10 - 20x slower than double (much better than 1000x) - basically for addition / multiplication. After benchmarking another algorithm which had a sequence of additions followed by an exponentiation the performance decrease was quite a bit worse: 200x - 400x. So it seems pretty fast for + and *, but not exp and log.

<blockquote>
 Commons Math is a library of lightweight, self-contained mathematics and statistics components addressing the most common problems not
 available in the Java programming language or Commons Lang.
</blockquote>

Note: The API protects the constructors to force a factory pattern while naming the factory DfpField (rather than the somewhat more intuitive DfpFac or DfpFactory). So you have to use 

<pre><code>new DfpField(numberOfDigits).newDfp(myNormalNumber)
</code></pre>

to instantiate a Dfp, then you can call <code>.multiply</code> or whatever on this. I thought I'd mention this because it's a bit confusing.

blocks|key|3125902|text|在64位的JVM上，创建如下所示的BigDecimal会使速度提高5倍左右：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3125903|BigDecimal+bd+=+new+BigDecimal(Double.toString(d),+MathContext.DECIMAL64);|code-block|syntax|javascript|3125904|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

On a 64bit JVM creating your BigDecimal as below makes it about 5x faster:

<pre><code>BigDecimal bd = new BigDecimal(Double.toString(d), MathContext.DECIMAL64);
</code></pre>

blocks|key|3125935|text|我知道这是一个非常老的帖子，但我正在写一个应用程序(顺便说一下，一个交易应用程序)，其中像MACD+(它计算多个指数移动平均值)这样的指标在几千个历史烛台上的计算花费了不可接受的时间(几分钟)。我用的是BigDecimal。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3125936|每次我滚动或调整窗口大小时，它都必须遍历缓存值来调整Y刻度的大小，但即使这样也需要几秒钟才能更新。这使得这个应用程序无法使用。每次我调整各种指标的参数时，都需要重新计算几分钟。|3125937|然后我把它都换成了双倍，速度快多了。问题是我使用hashmap缓存值。我提出的解决方案使用了一个用于双精度值的包装器池。通过池化包装器，您不会受到与Double之间的自动装箱对性能的影响。|3125938|该应用程序现在立即计算MACD+(%2BMACD信号，MACD直方图)，没有延迟。创建BigDecimal对象的代价之高令人惊讶。考虑一下a.add(+b.multiply(+C))、.scale(3)以及一条语句创建了多少个对象。|3125939|+import+java.util.HashMap;

public+class+FastDoubleMap<K>
{
++++private+static+final+Pool<Wrapper>+POOL+=+new+Pool<FastDoubleMap.Wrapper>()
++++{
++++++++protected+Wrapper+newInstance()
++++++++{
++++++++++++return+new+Wrapper();
++++++++}
++++};
++++
++++private+final+HashMap<K,+Wrapper>+mMap;
++++
++++public+FastDoubleMap()
++++{
++++++++mMap+=+new+HashMap<>();
++++}

++++public+void+put(+K+pKey,+double+pValue+)
++++{
++++++++Wrapper+lWrapper+=+POOL.checkOut();
++++++++lWrapper.mValue+=+pValue;
++++++++mMap.put(+pKey,+lWrapper+);
++++}
++++
++++public+double+get(+K+pKey+)
++++{
++++++++Wrapper+lWrapper++=+mMap.get(+pKey+);
++++++++if(+lWrapper+==+null+)
++++++++{
++++++++++++return+Double.NaN;
++++++++}
++++++++else
++++++++{
++++++++++++return+lWrapper.mValue;
++++++++}
++++}
++++
++++public+double+remove(+K+pKey+)
++++{
++++++++Wrapper+lWrapper+=+mMap.remove(+pKey+);
++++++++if(+lWrapper+!=+null+)
++++++++{
++++++++++++double+lDouble+=+lWrapper.mDouble;
++++++++++++POOL.checkIn(+lWrapper+);
++++++++++++return+lDouble;
++++++++}
++++++++else
++++++++{
++++++++++++return+Double.NaN;
++++++++}
++++}

++++private+static+class+Wrapper
++++++++implements+Pooled
++++{
++++++++private+double+mValue+;
++++++++
++++++++public+void+cleanup()
++++++++{
++++++++++++mValue+=+Double.NaN;
++++++++}
++++}
}|code-block|syntax|javascript|3125940|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|S|8|@]|9|@]|A|$K|L]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I know this is a really old thread, but i am writing an app (incidentally a trading app), in which computation of the indicators like MACD (which computes multiple exponential moving averages) over several thousand ticks of historical candlesticks was taking an unacceptable amount of time (several minutes). I was using BigDecimal.
every time i scrolled or resized the window, it would have to just iterate through the cached values to resize the Y scale, but even that would take several seconds to update. it made the app unusable. every time i would tweak the parameters for various indicators, it would take several minutes again to recompute.
then i switched it all to double and it's sooooo much faster. the problem was that i cache values using a hashmap. the solution i came up with uses a pool of wrappers for the double values. by pooling the wrappers, you don't take the performance hit of autoboxing to/from Double.
the app now calculates MACD (+MACD signal, MACD histogram) instantly with no lag. it's amazing how expensive BigDecimal object creation was. think about something like a.add( b.multiply( c )).scale(3) and how many objects that one statement creates.
<pre><code> import java.util.HashMap;

public class FastDoubleMap&lt;K&gt;
{
 private static final Pool&lt;Wrapper&gt; POOL = new Pool&lt;FastDoubleMap.Wrapper&gt;()
 {
 protected Wrapper newInstance()
 {
 return new Wrapper();
 }
 };
 
 private final HashMap&lt;K, Wrapper&gt; mMap;
 
 public FastDoubleMap()
 {
 mMap = new HashMap&lt;&gt;();
 }

 public void put( K pKey, double pValue )
 {
 Wrapper lWrapper = POOL.checkOut();
 lWrapper.mValue = pValue;
 mMap.put( pKey, lWrapper );
 }
 
 public double get( K pKey )
 {
 Wrapper lWrapper = mMap.get( pKey );
 if( lWrapper == null )
 {
 return Double.NaN;
 }
 else
 {
 return lWrapper.mValue;
 }
 }
 
 public double remove( K pKey )
 {
 Wrapper lWrapper = mMap.remove( pKey );
 if( lWrapper != null )
 {
 double lDouble = lWrapper.mDouble;
 POOL.checkIn( lWrapper );
 return lDouble;
 }
 else
 {
 return Double.NaN;
 }
 }

 private static class Wrapper
 implements Pooled
 {
 private double mValue ;
 
 public void cleanup()
 {
 mValue = Double.NaN;
 }
 }
}
</code></pre>

I write currency trading applications for living, so I have to work with monetary values (it's a shame that Java still doesn't have decimal float type and has nothing to support arbitrary-precision monetary calculations). "Use BigDecimal!" — you might say. I do. But now I have some code where performance is an issue, and BigDecimal is more than 1000 times (!) slower than <code>double</code> primitives.

The calculations are very simple: what the system does is calculating <code>a = (1/b) * c</code> many many times (where <code>a</code>, <code>b</code> and <code>c</code> are fixed-point values). The problem, however, lies with this <code>(1/b)</code>. I can't use fixed point arithmetic because there is no fixed point. And <code>BigDecimal result = a.multiply(BigDecimal.ONE.divide(b).multiply(c)</code> is not only ugly, but sluggishly slow.

What can I use to replace BigDecimal? I need at least 10x performance increase. I found otherwise excellent <a href="http://www.jscience.org" rel="noreferrer" title="JScience">JScience library</a> which has arbitrary-precision arithmetics, but it's even slower than BigDecimal.

Any suggestions?

What to do with Java BigDecimal performance?

数据库

编译器

Java

我编写货币交易应用程序是为了谋生，所以我必须处理货币值(遗憾的是，Java仍然没有decimal float类型，也没有支持任意精度的货币计算)。“使用BigDecimal!”--你可能会说。我知道。但现在我有一些代码，其中性能是的一个问题，而BigDecimal超过1000倍(!)比double原语慢。计算非常简单:...

问如何处理Java BigDecimal性能？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何处理Java BigDecimal性能？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何处理Java BigDecimal性能？
EN