Re: Why Git is so fast

Kjetil Barvik [off-list ref] wrote:

* "Shawn O. Pearce" [off-list ref] 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.