On Wed, Feb 12, 2014 at 12:27 PM, Stefan Zager <szager@xxxxxxxxxxxx> wrote: > On Wed, Feb 12, 2014 at 12:06 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Stefan Zager <szager@xxxxxxxxxxxx> writes: >> >> Calls to write (and preparation of data to be written) will then >> remain single-threaded, but it sounds like that codepath is not the >> bottleneck in your measurement, so.... > > Yes, I considered that as well. At a minimum, that would still > require attr.c to implement thread locking, since attribute files must > be parsed to look for stream filters. I have already done that work. I would have imagined that use of the attribute system belongs to "write and preparation of data to be written" category, i.e. the single threaded part of the kludge I outlined. > But I'm not sure it's the best long-term approach to add convoluted > custom threading solutions to each git operation as it appears on the > performance radar. Yeah, it depends on how clean and non-intrusive an abstraction we can make. The kludge I outlined is certainly not very pretty. -- 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