Re: Why Git is so fast

From

Shawn O. Pearce <spearce@spearce.org>

Date

Apr 30, 2009, 20:40 UTC

Message-ID

<20090430204033.GV23604@spearce.org>

In-Reply-To

<86iqkllw0c.fsf@broadpark.no>

Kjetil Barvik <barvik@broadpark.no> wrote:

> * "Shawn O. Pearce" <spearce@spearce.org> writes:
>  <snipp>
> | - Avoid allocating byte[] for SHA-1s, instead we convert to 5 ints,
> |   which can be inlined into an object allocation.
> 
>   What to pepole think about doing something simmilar in C GIT?
> 
>   That is, convert the current internal representation of the SHA-1 from
>   "unsigned char sha1[20]" to "unsigned long sha1[5]"?

Its not worth the code churn.
 

>   Ok, I currently see 2 problems with it:
> 
>      1) Will the type "unsigned long" always be unsigned 32 bit on all
>         platforms on all computers?  do we need an "unit_32_t" thing?

Yea, "unsigned long" isn't always 32 bits.  So we'd need to use
uint32_t.  Which we already use elsewhere, but still.
 

>      2) Can we get in truble because of differences between litle- and
>         big-endian machines?

>      4) The "static inline void hashcpy(....)" in cache.h could then
>         maybe be written like this:

Its already done as "memcpy(a, b, 20)" which most compilers will
inline and probably reduce to 5 word moves anyway.  That's why
hashcpy() itself is inline.
 

-- 
Shawn.