On Fri, Jul 05, 2019 at 02:45:16PM +0900, Mike Hommey wrote: > On Fri, Jul 05, 2019 at 01:09:55AM -0400, Jeff King wrote: > > On Thu, Jul 04, 2019 at 07:05:30PM +0900, Mike Hommey wrote: > > > Finally, with 1 thread, the picture changes greatly. The overall process > > > takes 2.5h: > > > - 50 seconds enumerating and counting objects. > > > - ~2.5h compressing objects. > > > - 3 minutes and 25 seconds writing objects! > > > > That's weird. I'd expect us to find similar amounts of deltas, but we > > don't have the writing slow-down. I wonder if there is some bad > > interaction between the multi-threaded code and the delta cache. > > > > Did you run the second, single-thread run against the exact same > > original repository you had? Or did you re-run it on the result of the > > multi-thread run? Another explanation is that the original repository > > had some poor patterns that made objects expensive to access (say, a ton > > of really deep delta chains). And so the difference between the two runs > > was not the threads, but just the on-disk repository state. > > > > Kind of a long shot, but if that is what happened, try running another > > multi-threaded "repack -f" and see if its writing phase is faster. > > I've run 36-threads, 16-threads and 1-thread in sequence on the same > repo, so 16-threads was repacking what was repacked by the 36-threads, > and 1-thread was repacking what was repacked by the 16-threads. I > assumed it didn't matter, but come to think of it, I guess it can.
I tried: - fresh clone -> 36-threads - fresh clone -> 1-thread -> 36-threads The 36-threads gc in the latter was only marginally faster than in the former (between 19 and 20 minutes instead of 22 for both "Compressing" and "Writing"). Mike
