Does this really add comparisons on average? Or does it only add comparisons on key equality? If the latter the difference is definitely minute.
Secondly, changing comparator value to include value changes how sets work. Usually, this is good. Occasionally bad. In any case, a change that is rather subtle and difficult to determine whether there is an impact. On Wed, Oct 16, 2013 at 10:10 PM, Sean Owen <sro...@gmail.com> wrote: > 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 > > > > >
