Kjetil Barvik <barvik@xxxxxxxxxxxx> wrote: > * "Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html