Stefan Zager <szager@xxxxxxxxxxxx> writes: > On Tue, Feb 11, 2014 at 6:11 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: >> >> I have no comments about thread safety improvements (well, not yet). >> If you have investigated about git performance on chromium >> repositories, could you please sum it up? Threading may be an option >> to improve performance, but it's probably not the only option. > > Well, the painful operations that we use frequently are pack-objects, > checkout, status, and blame. Have you checked the patch in <URL:http://thread.gmane.org/gmane.comp.version-control.git/241448> and followups, Message-ID: <1391454849-26558-1-git-send-email-dak@xxxxxxx>? While this does not yet support -M and -C options, it's conceivable that you don't use them in your server/scripts. > Anything on Windows that touches a lot of files is miserable due to > the usual file system slowness on Windows, and luafv.sys (the UAC file > virtualization driver) seems to make it much worse. There is an obvious solution here... Dedicated hardware is not that expensive. Virtualization will always have a price. > Blame is something that chromium and blink developers use heavily, and > it is not unusual for a blame invocation on the blink repository to > run for 30 seconds. It seems like it should be possible to > parallelize blame, but it requires pack file operations to be > thread-safe. Really, give the above patch a try. I am taking longer to finish it than anticipated (with a lot due to procrastination but that is, unfortunately, a large part of my workflow), and it's cutting into my "paychecks" (voluntary donations which to a good degree depend on timely and nontrivial progress reports for my freely available work on GNU LilyPond). Note that it looks like the majority of the remaining time on GNU/Linux tends to be spent in system time: I/O time, memory management. And I have an SSD drive. When using packed repositories of considerable size, decompression comes into play as well. I don't think that you can hope to get noticeably higher I/O throughput by multithreading, so really, really, really consider dedicated hardware running on a native Linux file system. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html