From: Shawn O. Pearce <spearce@spearce.org>
Date: Thu, 30 Apr 2009 20:40:33 GMT
Subject: Re: Why Git is so fast
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?

Yes, especially if compare was implemented using native uint32_t
compare and the processor was little-endian.

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