Re: [PATCH v2 0/4] Speed up unpack_trees()
- From
Ben Peart <peartben@gmail.com>
- Date
- Jul 30, 2018, 21:04 UTC
- Message-ID
- <dfe67a11-8b0b-682e-ff6c-4341808339bc@gmail.com>
- In-Reply-To
- <20180729103306.16403-1-pclouds@gmail.com>
On 7/29/2018 6:33 AM, Nguyễn Thái Ngọc Duy wrote:
Show 32 quoted lines
> This series speeds up unpack_trees() a bit by using cache-tree. > unpack-trees could bit split in three big parts > > - the actual tree unpacking and running n-way merging > - update worktree, which could be expensive depending on how much I/O > is involved > - repair cache-tree > > This series focuses on the first part alone and could give 700% > speedup (best case possible scenario, real life ones probably not that > impressive). > > It also shows that the reparing cache-tree is kinda expensive. I have > an idea of reusing cache-tree from the original index, but I'll leave > that to Ben or others to try out and see if it helps at all. > > v2 fixes the comments from Junio, adds more performance tracing and > reduces the cost of adding index entries. > > Nguyễn Thái Ngọc Duy (4): > unpack-trees.c: add performance tracing > unpack-trees: optimize walking same trees with cache-tree > unpack-trees: reduce malloc in cache-tree walk > unpack-trees: cheaper index update when walking by cache-tree > > cache-tree.c | 2 + > cache.h | 1 + > read-cache.c | 3 +- > unpack-trees.c | 161 ++++++++++++++++++++++++++++++++++++++++++++++++- > unpack-trees.h | 1 + > 5 files changed, 166 insertions(+), 2 deletions(-) >
I have a limited understanding of this code path so I'm not the best person to review this but I didn't see any issues that concerned me. I also was able to run our internal functional and performance tests in addition to the git tests and the results were positive.
Ben