Re: Some rough edges of core.fsmonitor
- From
Ben Peart <peartben@gmail.com>
- Date
- Jan 29, 2018, 23:16 UTC
- Message-ID
- <bb8a433f-bd61-1f3c-2034-1acc96539882@gmail.com>
- In-Reply-To
- <20180129094033.GA8670@ash>
On 1/29/2018 4:40 AM, Duy Nguyen wrote:
Show 9 quoted lines
> On Sat, Jan 27, 2018 at 12:43:41PM +0100, Ævar Arnfjörð Bjarmason wrote: >> b) with fsmonitor >> >> $ time GIT_TRACE_PERFORMANCE=1 ~/g/git/git-status >> 12:34:23.833625 read-cache.c:1890 performance: 0.049485685 s: read cache .git/index > > This is sort of off topic but may be interesting for big repo guys. It > looks like read cache's time is partially dominated by malloc(). >
That is correct. We have tried a few different ways to address this. First was my patch series [1] that would parallelize all of the read cache code.
We quickly found that malloc() was the biggest culprit and by speeding that up, we got most of the wins. At Peff's recommendation [2], we looked into using tcmalloc but found that 1) it has bugs on Windows and 2) it isn't being actively maintained so it didn't seem those bugs would ever get fixed.
We are currently working on a patch that will use a refactored version of the mem_pool in fast-import.c to do block allocations of the cache entries which is giving us about a 22% improvement in "git status" times. One challenge has been ensuring that cache entries are not passed from one index/mem_pool to another which could cause access after free bugs.
[1] https://public-inbox.org/git/20171109141737.47976-1-benpeart@microsoft.com/ [2] https://public-inbox.org/git/20171120153846.v5b7ho42yzrznqoh@sigill.intra.peff.net/
Show 64 quoted lines
> This is the performance breakdown of do_read_index()
>
> $ GIT_TRACE_PERFORMANCE=2 ~/w/git/t/helper/test-read-cache
> 0.000078489 s: open/mmap/close
> 0.038915239 s: main entries
> 0.018983150 s: ext TREE
> 0.012667080 s: ext UNTR
> 0.000005372 s: ext FSMN
> 0.001473470 s: munmap
> 0.072386911 s: read cache .git/index
>
> Reading main index entries takes like half of the time (0.038 vs
> 0.072). With the below patch to take out hundred thousands of malloc()
> we have this, loading main entries now only takes 0.012s:
>
> $ GIT_TRACE_PERFORMANCE=2 ~/w/git/t/helper/test-read-cache
> 0.000046587 s: open/mmap/close
> 0.012077300 s: main entries
> 0.020477683 s: ext TREE
> 0.010259998 s: ext UNTR
> 0.000010250 s: ext FSMN
> 0.000753854 s: munmap
> 0.043906473 s: read cache .git/index
>
> We used to do less malloc until debed2a629 (read-cache.c: allocate
> index entries individually - 2011-10-24) but I don't think we can
> simply revert that (not worth the extra complexity of the old way).
>
> Now "TREE" and "UNTR" extensions become a bigger problem.
>
> -- 8< --
> diff --git a/read-cache.c b/read-cache.c
> index d60e0a8480..88f4213c99 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1622,7 +1622,12 @@ static struct cache_entry *cache_entry_from_ondisk(struct ondisk_cache_entry *on
> const char *name,
> size_t len)
> {
> +#if 0
> struct cache_entry *ce = xmalloc(cache_entry_size(len));
> +#else
> + static char buf[1024];
> + struct cache_entry *ce = (struct cache_entry *)buf;
> +#endif
>
> ce->ce_stat_data.sd_ctime.sec = get_be32(&ondisk->ctime.sec);
> ce->ce_stat_data.sd_mtime.sec = get_be32(&ondisk->mtime.sec);
> diff --git a/t/helper/test-read-cache.c b/t/helper/test-read-cache.c
> index 48255eef31..e1d21d17a3 100644
> --- a/t/helper/test-read-cache.c
> +++ b/t/helper/test-read-cache.c
> @@ -8,7 +8,9 @@ int cmd_main(int argc, const char **argv)
> setup_git_directory();
> for (i = 0; i < cnt; i++) {
> read_cache();
> +#if 0
> discard_cache();
> +#endif
> }
> return 0;
> }
> -- 8< --
>