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. Phil > >>>> 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
