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