On Wed, Feb 12, 2014 at 12:27 PM, Stefan Zager <sza...@chromium.org> wrote:
> On Wed, Feb 12, 2014 at 12:06 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> Stefan Zager <sza...@chromium.org> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html