From: Jakub Narebski <jnareb@gmail.com>
Date: Sat, 07 Apr 2018 18:40:59 GMT
Subject: Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph
Message-ID: <86y3hyeu6c.fsf@gmail.com>
In-Reply-To: <20180406190919.167092-1-dstolee@microsoft.com>

Derrick Stolee <dstolee@microsoft.com> writes:

[...]
> 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