[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] (x)memcoll: performance improvement when input is known to b

From: Chen Guo
Subject: Re: [PATCH] (x)memcoll: performance improvement when input is known to be NUL delimited.
Date: Mon, 8 Mar 2010 19:33:31 -0800 (PST)

Hi Bruno,

    I'm going through and applying your suggestions, and I'm a bit iffy on this
> > +/* 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)
> > +{
> > +  int diff;
> 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 conditional
branches, that may more than cancel out any speedups we gain.

    For an extreme example, memcoll isn't threadsafe, but there isn't a
safety check of locking down the strings before writing a NUL byte to
the end.

    Could we just document it clearly that the (x)memcoll0 functions
absolutely require both S1 and S2 to be NUL delimited, and thus
leave it up to the user to know the usage?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]