Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

From: Jakub Narebski <jnareb@gmail.com>
Date: Apr 7, 2018, 18:40 UTC
Message-ID: <86y3hyeu6c.fsf@gmail.com>
In-Reply-To: <20180406190919.167092-1-dstolee@microsoft.com>

Derrick Stolee <dstolee@microsoft.com> writes:

[...]

Show 12 quoted lines

> On the Linux repository, performance tests were run for the following
> command:
>
>     git log --graph --oneline -1000
>
>     Before: 0.92s
>     After:  0.66s
>     Rel %: -28.3%
>
> Adding '-- kernel/' to the command requires loading the root tree
> for every commit that is walked. There was no measureable performance
> change as a result of this patch.

In the "Git Merge contributor summit notes" [1] one can read that:

> - VSTS adds bloom filters to know which paths have changed on the commit
> - tree-same check in the bloom filter is fast; speeds up file history checks
> - if the file history is _very_ sparse, then bloom filter is useful

Could this method speed up also the second case mentioned here? Can anyone explain how this "path-changed bloom filter" works in VSTS?

Could we add something like this to the commit-graph file?

[1]: https://public-inbox.org/git/alpine.DEB.2.20.1803091557510.23109@alexmv-linux/

Best regards, -- Jakub Narębski