Re: [PATCH] (x)memcoll: performance improvement when input is known to be NUL delimited.

[Bruno Haible]

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 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?

Correct execution of a program is more important than its speed. My
math teacher used to say, when talking about the floating-point operations
of the CDC Cyber computers he used: "This computer produces wrong results,
but it does so very fast." (These float operations were not IEEE compliant.
They implemented round-towards-zero for each operation, not round-to-even.
Thus rounding errors accumulated in one direction.)

Safety checks reduce the probability of incorrect programming. If the
probability that a programmer mis-uses an API is 10%, leading to incorrect
results, is it not worth spending 1% of execution time to avoid this?

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.

About safety checks against multithread-related programming errors: In C
this is not possible, because there is no direct relation between locks
and locked objects in memory, but in programming languages where it is
possible, it is being successfully done. In Java, for example, when one
thread iterates over a hash table and another thread modifies it at the
same time, you get an exception. I've seen such exceptions numerous times.
Given that each such check is an O(1) operation - just a few instructions -,
it is certainly worth it.

Bruno