You are right that it adds 1 or 2 more branches per comparison. The new Comparator would at least be consistent with equals(), though it probably doesn't matter for correctness in practice.
I am interested in closing this minor issue so I suggest you ignore this part if you guess that this overhead is too much, and that it's not worth offering this for other callers of CM. I'll just maintain my own copy. On Wed, Oct 16, 2013 at 9:56 PM, Gilles <gil...@harfang.homelinux.org>wrote: > > > The potential problem is performance. The current code for "sortInPlace" is > not as fast as it could be, very probably because it uses a Comparator. > IIUC, > using your new comparator will add another "if" (to test whether comparing > the > "value"s is necessary). [And "reverseOrder" will also add a few operations > on > its own, I guess.] > It would be nice to know whether the impact is really fairly negligible, or > not. > > There is a class (in the "test" part of repository) for performing simple > benchmarks: > org.apache.commons.math3.**PerfTestUtils > that tries to provide fair comparison results by interleaving calls to two > (or more) alternative codes. > > > Best regards, > > Gilles > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > >
