On Sun, 09 Sep 2007 02:37:18 +0200, Pierre Habouzit wrote:

quoted text
> On Sat, Sep 08, 2007 at 11:50:34PM +0000, Andreas Ericsson wrote:

quoted text
>> But this introduces handy but, strictly speaking, unnecessary overhead
>> as well, meaning, in short; 'D is slower than C, but easier to write
>> code in'.
> 
>   That's BS. See the strbuf API I've been pushing recently ? It has
> simplified git's code a lot, because each time git had to deal with a
> growing string, it had to deal with at least three variables: the buffer
> pointer, the current occupied length, and its allocated size. That was
> three thing to have variable names for, and to pass to functions.
> 
>   Now instead, it's just one struct. D gives that gratis. There is no
> performance loss because you _need_ to do the same. How do you deal with
> dynamic arrays if you dont't store their lenght and size somewhere ?

 Some string APIs don't store the size, some include the bytes in the
"struct" itself using the struct hack, in C. For instance ustr uses 
3 bytes more than strdup(), by default, for "small" strings[1] -- which
includes a size, length, reference counting and a "memory failure occured"
error.

 On the other extreme, C++ strings or Vstr take up much more than
12/24[2] bytes (because they are designed to be used differently) and
strbuf itself takes up 16/20[2] bytes.

 Note that I'm not saying you shouldn't use a decent string API, quite
the opposite, but assuming that "whatever is embedded in the language"
is good enough for all purposes is far from reality.


[1] 1-255 bytes is "small", for obvious reasons you need one more byte
after that (note that "", 0 byte strings, don't take any bytes to store
with ustr).

[2] 32bit/64bit sizes

-- 
James Antill -- james@and.org
C String APIs use too much memory? ustr: length, ref count, size and
read-only/fixed. Ave. 44% overhead over strdup(), for 0-20B strings
http://www.and.org/ustr/

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html