Hi,
On Wed, 25 Jan 2017, Jeff King wrote:
> On Wed, Jan 25, 2017 at 07:43:01PM +0100, René Scharfe wrote:
>
> > If we find such cases then we'd better fix them for all platforms, e.g. by
> > importing timsort, no?
>
> Yes, as long as they are strict improvements.
I think in many cases, we may
On Wed, Jan 25, 2017 at 07:43:01PM +0100, René Scharfe wrote:
> 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
>
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
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.
Am 23.01.2017 um 20:07 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Implement qsort_s() as a wrapper to the GNU version of qsort_r(1) and
>> use it on Linux. Performance increases slightly:
>>
>> Test HEAD^ HEAD
>>
René Scharfe writes:
> Implement qsort_s() as a wrapper to the GNU version of qsort_r(1) and
> use it on Linux. Performance increases slightly:
>
> Test HEAD^ HEAD
>
> 0071.2:
Implement qsort_s() as a wrapper to the GNU version of qsort_r(1) and
use it on Linux. Performance increases slightly:
Test HEAD^ HEAD
0071.2: sort(1) 0.10(0.20+0.02)
7 matches
Mail list logo