Am 24.01.2017 um 21:39 schrieb Jeff King:
On Tue, Jan 24, 2017 at 07:00:03PM +0100, René Scharfe wrote:
I do worry about having to support more implementations in the
future that have different function signature for the comparison
callbacks, which will make things ugly, but this addition alone
doesn't look too bad to me.
It is unfair of me to show a 5% speedup and then recommend to not
include it. ;-) That difference won't be measurable in real use cases
and the patch is not necessary. This patch is simple, but the overall
complexity (incl. #ifdefs etc.) will be lower without it.
I care less about squeezing out the last few percent performance and
more that somebody libc qsort_r() might offer some other improvement.
For instance, it could sort in-place to lower memory use for some cases,
or do some clever thing that gives more than a few percent in the real
world (something like TimSort).
I don't know to what degree we should care about that.
That's a good question. Which workloads spend a significant amount of
time in qsort/qsort_s?
We could track processor time spent and memory allocated in QSORT_S and
the whole program and show a warning at the end if one of the two
exceeded, say, 5% of the total, asking nicely to send it to our mailing
list. Would something like this be useful for other functions or
metrics as well? Would it be too impolite to use users as telemetry
transports?
If we find such cases then we'd better fix them for all platforms, e.g.
by importing timsort, no?
René
