> Right, the format and implementation in JGit can do "Counting objects"
> in 87ms for the Linux kernel history.
Actually, that was the timing when I first pushed the change. With the
improvements submitted throughout the year, we can do counting in
50ms, on my same machine.
> But I think we are
> + Generating this reverse index at runtime is **not** free (around 900ms
> + generation time for a repository like `torvalds/linux`), and once again,
> + this generation time needs to happen every time `pack-objects` is
> + spawned.
If generating the reverse index is expensive, it is probabl
>> 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
> 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
4 matches
Mail list logo