On 07/08/10 14:23, Pádraig Brady wrote:
> This has finally come through.
> Can we apply this please.
Done, here:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=9f31a7914f9d65fbc1225f503491dcc90e90c357
Thanks for contributing, Chen!
On 21/04/10 11:20, Bruno Haible wrote:
> Hi Chen,
>
>> I mailed my signature off a good month ago, it should be. Bruno,
>> did you get anything from the FSF yet?
>
> No, I didn't get a notification from the FSF so far, and the copyright.list
> on FSF machines (which was last modified yesterday) d
Hi Chen,
> I mailed my signature off a good month ago, it should be. Bruno,
> did you get anything from the FSF yet?
No, I didn't get a notification from the FSF so far, and the copyright.list
on FSF machines (which was last modified yesterday) does not contain your
name either, today.
I guess w
Hi Padraig,
> From: Pádraig Brady
> To: Bruno Haible
> Cc: Chen Guo ; bug-gnulib@gnu.org
> Sent: Wed, April 21, 2010 1:46:47 AM
> Subject: Re: [PATCH] (x)memcoll: performance improvement when input is known
> to be NUL delimited.
>
> On 14/03/10 14:24, Bruno
On 14/03/10 14:24, Bruno Haible wrote:
> Hi Chen,
>
>> ... it was consistently (as in every run for 20 runs) faster, and thus I've
>> included it in the patch.
>
> Thanks. I'll wait for the FSF notification that the legal papers have arrived.
Hi Chen, The copyright stuff is sorted now I presume
Paolo Bonzini wrote:
> On 03/14/2010 03:15 PM, Bruno Haible wrote:
>> Here, the calling convention of providing a string with a size, and the
>> size must include the trailing NUL byte, is so unusual that the probability
>> of a mis-use of the API is likely 10% or more.
>
> You can always use asser
On 03/14/2010 03:15 PM, Bruno Haible wrote:
Here, the calling convention of providing a string with a size, and the
size must include the trailing NUL byte, is so unusual that the probability
of a mis-use of the API is likely 10% or more.
You can always use assert so that #define NDEBUG would c
Hi Chen,
> ... it was consistently (as in every run for 20 runs) faster, and thus I've
> included it in the patch.
Thanks. I'll wait for the FSF notification that the legal papers have arrived.
> This is not what I expected at all, and I'm having a hard time coming up with
> a reason why this i
Hi Chen,
> > It would be good to start the function with a safety check:
> >
> > if (!(s1len > 0 && s1[s1len - 1] == '\0'))
> >abort ();
> > if (!(s2len > 0 && s2[s2len - 1] == '\0'))
> >abort ();
>
> If the whole point was performance, but we introduce 4 conditiona
On 11/03/10 17:10, Chen Guo wrote:
> Hi Padraig,
> Thanks for the _unlikely insight, that explains why it's not slower
> but the speed up is still quite mysterious. When I ran with the line
> lengths you wanted, with check it is no longer faster, but something
> else I don't quite understand po
Hi Padraig,
Thanks for the _unlikely insight, that explains why it's not slower
but the speed up is still quite mysterious. When I ran with the line
lengths you wanted, with check it is no longer faster, but something
else I don't quite understand pops up.
The file I usually test on is 1M
On 10/03/10 07:05, Chen Guo wrote:
Hi Bruno,
I tried with the checks for the presence of that last NUL byte like you
suggested,
> and to my surprise on the remote machine I was testing on it was consistently
> (as in every run for 20 runs) faster, and thus I've included it in the patch.
> This
luded
in memcoll.c instead, since that's what xmemcoll.c includes.
>From 19516c730bced56670d180899d099e18be2a9ae3 Mon Sep 17 00:00:00 2001
From: Chen Guo
Date: Sun, 7 Mar 2010 17:07:49 -0800
Subject: [PATCH] (x)memcoll: performance improvement when input is known to be
NUL delimited.
Thi
Hi Bruno,
I'm going through and applying your suggestions, and I'm a bit iffy on this
one:
> > +/* Like memcoll, but S1 and S2 are known to be NUL delimited, thus no
> > + modification to S1 or S2 are needed. */
> > +int
> > +memcoll_nul (char *s1, size_t s1len, char *s2, size_t s2len)
> >
Hi Bruno,
I'll make all the changes you proposed, except this I have some questions
about:
> For each input line, xmemcoll is called multiple times? Then you can certainly
> gain much more speed than 1% by replacing memcoll with 2 x memxfrm and
> 1 x memcmp2. Of course, the 'sort' program w
Hi Chen,
Thanks for your submission! I think your patch is a useful addition to the
'memcoll' and 'xmemcoll' modules.
The code in gnulib should be copyright-assigned to the FSF. This is necessary,
in order to be on the safe side, legally, should disputes à la SCO happen in
the future. Is it a pos
001
From: Chen Guo
Date: Sun, 7 Mar 2010 17:07:49 -0800
Subject: [PATCH] (x)memcoll: performance improvement when input is known to be
NUL delimited.
This is in suport of a patch to coreutils' sort, where for each
input line xmemcoll is called several times. If each input line is
NUL delimi
Hi all,
I'm submitting a performance patch to sort soon that requires this for one
of the patch's smaller optimizations, but hey, 1% is 1%.
nul_patch
Description: Binary data
18 matches
Mail list logo
