Re: Why Git is so fast

[Kjetil Barvik <barvik@broadpark.no>]

* "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]"?

  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?

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

  And, simmilar I can see or guess the following would be positive with
  this change:

     3) From a SHA1 library I worked with some time ago, I noticed that
        it internaly used the type "unsigned long arr[5]", so it can
        mabye be possible to get some shurtcuts or maybe speedups here,
        if we want to do it.

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

  static inline void hashcpy(unsigned long sha_dst[5], const unsigned long sha_src[5])
  {
       sha_dst[0] = sha_src[0];
       sha_dst[1] = sha_src[1];
       sha_dst[2] = sha_src[2];
       sha_dst[3] = sha_src[3];
       sha_dst[4] = sha_src[4];
  }

        And hopefully will be compiled to just 5 store/more
        instructions, or at least hopefully be faster than the currently
        memcpy() call. But mabye we get more compiled instructions compared
        to a single call to memcpy()?

     5) Simmilar as 4) for the other SHA1 realted hash functions nearby
        hashcpy() in cache.h

  OK, just some thought's.  Sorry if this allready has been discussed
  but could not find something abouth it after a simple google search.

  -- kjetil