commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] Complex division
Date Sun, 04 Sep 2011 15:56:03 GMT
On 9/4/11 6:01 AM, Gilles Sadowski wrote:
>>> [...]
>> The hit is in the constructor, where every complex instance has to
>> run the code to set the property.
> In fact, not only! If one can trust the mini-benchmark performed with
> "PerfTestUtils", the constructor with the additional flag is 2% slower.
> But using the flag in "divide" makes it also _slower_ (3 per 1000 even for
> division by zero), contrary to my expectations. [All of these operations
> taking the order of 10 to 60 microseconds, relativizing the loss of
> performance.]

The constructor hit is what I was most worried about, since it
impacts every instantiation.   The other thing that I was thinking
explains the counter-intuitive result on the flag.  Assuming you are
using stochastically generated values, the probability that the
first comparison in the flag-less code will succeed is miniscule
(zero actually, mathemtically but 1/(number of representable
doubles) in practice), so given the short-circuit evaluation and the
fact that a double equality check is probably optimized to be not
much if at all more expensive than a test on a boolean, it makes
sense that adding the flag won't improve performance in most cases
and the overhead of the method call to read it might actually
hurt.   This is a little unfair because I expect exact 0's to be
more likely in practice.

>>>> This, btw, is yet another reason to separate commits.
>>> OK, I take this as: You would have only "cleanly reverted" the Javadoc
>>> change, if it would have been separate. I'll thus commit back the rest.
>> Please do not add back the extra property.
> I apologize for not having heeded to the advice that timing results do not
> always agree with what the code would seem to imply for a naive reader.
> [A wild guess would be that comparing with 0.0 is more apt to optimization
> by the JVM than a boolean check (?). Or could it vary from processor to
> processor and from JVM to JVM and from JVM version to JVM version?  Then,
> if we are below some reasonable performance quality (i.e. relative to all
> the other operations required from an "average" and "useful" application);
> I think that it is all the more worth improving the consistency of the
> "Complex" class (even if just to avoid those time-consuming discussions to
> pop up again in the future!).]
> It would be useful to hear others on this last point, in order to start (or
> not) a reflexion on a global policy for code improvement along several axes
> (consistency vs performance vs readability vs self-documenting vs ...) which
> would maybe result in objective rules that will help to decide whether a
> change is acceptable, based on clearly defined trade-offs.
> That would hopefully be helpful to avoid such situations where one makes a
> change because he likes it, and another refuses the change because he does
> not like it; if you see what I mean.
> In my opinion, a necessary step in that direction would be to set up a
> "framework" for performance tests with baseline acceptable values for
> selected sets of realistic use-cases. I think that many committers here
> could readily come up with such use-cases.
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message