On Wed, 16 Oct 2013 22:10:33 +0100, Sean Owen 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.
No problem for me. Please indicate on JIRA that you are satisfy with
what is
currently in trunk with respect to MATH-1041, and I'll resolve the
issue.
[You also open another "wish" and move your patch for the comparator
there;
thus we can keep track of it, and someone can possibly do the benchmark
later.]
Thanks,
Gilles
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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
