On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup <dak@xxxxxxx> wrote: > Stefan Zager <szager@xxxxxxxxxxxx> writes: > >> 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. Not sure I follow you. We need to support people developing, building, and testing on natively Windows machines. And we need to support users with reasonable hardware, including spinning disks. If we were only interested in optimizing for Google employees, each of whom has one or more small nuclear reactors under their desk, this would be easy. >> 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). I will give that a try. How much of a performance improvement have you clocked? > 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. I have a background in hardware, and I have much more faith in modern disk schedulers :) Stefan -- 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