From: René Scharfe Date: Wed, 25 Jan 2017 18:43:01 GMT Subject: Re: [DEMO][PATCH v2 6/5] compat: add a qsort_s() implementation based on GNU's qsort_r(1) Message-ID: In-Reply-To: <20170124203949.46lbmiyj26xx4hrk@sigill.intra.peff.net> 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é