> Pinning the bitmap index on the reverse index adds complexity (lookups > are two-step: first find the entry in the reverse index, and then find > the SHA1 in the index) and is measurably slower, in both loading and > lookup times. Since Git doesn't have a memory problem, it's very hard > to make an argument for design that is more complex and runs slower to > save memory.
Sorting by SHA1 will generate a random distribution. This will require you to inflate the entire bitmap on every fetch request, in order to do the "contains" operation. Sorting by pack offset allows us to inflate only the bits we need as we are walking the graph, since they are usually at the start of the bitmap. What is the general size in bytes of the SHA1 sorted bitmaps? If they are much larger, the size of the bitmap has an impact on how fast you can perform bitwise operations on them, which is important for fetch when doing wants AND NOT haves. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
