commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] Complex division
Date Sun, 04 Sep 2011 13:01:20 GMT
> > [...]
> 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

> >
> >> 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.


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

View raw message