Re: [PATCH v2 0/4] Speed up unpack_trees()

2018-08-10 Thread Duy Nguyen
On Thu, Aug 9, 2018 at 10:16 AM Ben Peart wrote: > In fact, in the other [1] patch series, we're detecting the number of > cache entries that are the same as the cache tree and using that to > traverse_by_cache_tree(). At that point, couldn't we copy the > corresponding cache tree entries over to

Re: [PATCH v2 0/4] Speed up unpack_trees()

2018-08-10 Thread Duy Nguyen
On Wed, Aug 8, 2018 at 10:53 PM Ben Peart wrote: > > > > On 8/1/2018 12:38 PM, Duy Nguyen wrote: > > On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote: > >> > >> > >> On 7/31/2018 12:50 PM, Ben Peart wrote: > >>> > >>> > >>> On 7/31/2018 11:31 AM, Duy Nguyen wrote: > >> > > > In t

Re: [PATCH v2 0/4] Speed up unpack_trees()

2018-08-09 Thread Ben Peart
On 8/8/2018 4:53 PM, Ben Peart wrote: On 8/1/2018 12:38 PM, Duy Nguyen wrote: On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote: On 7/31/2018 12:50 PM, Ben Peart wrote: On 7/31/2018 11:31 AM, Duy Nguyen wrote: In the performance game of whack-a-mole, that call to repair c

Re: [PATCH v2 0/4] Speed up unpack_trees()

2018-08-08 Thread Ben Peart
On 8/1/2018 12:38 PM, Duy Nguyen wrote: On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote: On 7/31/2018 12:50 PM, Ben Peart wrote: On 7/31/2018 11:31 AM, Duy Nguyen wrote: In the performance game of whack-a-mole, that call to repair cache-tree is now looking quite expensive.

Re: [PATCH v2 0/4] Speed up unpack_trees()

2018-08-01 Thread Duy Nguyen
On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote: > > > On 7/31/2018 12:50 PM, Ben Peart wrote: > > > > > > On 7/31/2018 11:31 AM, Duy Nguyen wrote: > > >> > >>> In the performance game of whack-a-mole, that call to repair cache-tree > >>> is now looking quite expensive... > >> > >> Y

Re: [PATCH v2 0/4] Speed up unpack_trees()

2018-07-31 Thread Ben Peart
On 7/31/2018 12:50 PM, Ben Peart wrote: On 7/31/2018 11:31 AM, Duy Nguyen wrote: In the performance game of whack-a-mole, that call to repair cache-tree is now looking quite expensive... Yeah and I think we can whack that mole too. I did some measurement. Best case possible, we just n

Re: [PATCH v2 0/4] Speed up unpack_trees()

2018-07-31 Thread Ben Peart
On 7/31/2018 11:31 AM, Duy Nguyen wrote: On Mon, Jul 30, 2018 at 8:10 PM Ben Peart wrote: I ran "git checkout" on a large repo and averaged the results of 3 runs. This clearly demonstrates the benefit of the optimized unpack_trees() as even the final "diff-index" is essentially a 3rd call

Re: [PATCH v2 0/4] Speed up unpack_trees()

2018-07-31 Thread Duy Nguyen
On Mon, Jul 30, 2018 at 8:10 PM Ben Peart wrote: > I ran "git checkout" on a large repo and averaged the results of 3 runs. > This clearly demonstrates the benefit of the optimized unpack_trees() > as even the final "diff-index" is essentially a 3rd call to unpack_trees(). > > baselinene

Re: [PATCH v2 0/4] Speed up unpack_trees()

2018-07-30 Thread Ben Peart
On 7/29/2018 6:33 AM, Nguyễn Thái Ngọc Duy wrote: 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 i

Re: [PATCH v2 0/4] Speed up unpack_trees()

2018-07-30 Thread Ben Peart
On 7/29/2018 6:33 AM, Nguyễn Thái Ngọc Duy wrote: 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 i

[PATCH v2 0/4] Speed up unpack_trees()

2018-07-29 Thread Nguyễn Thái Ngọc Duy
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