Junio C Hamano <gitster@pobox.com> writes:

quoted text
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> ... (except, as we found out last week, we've had a huge 
>> performance regression, so that's actually a really slow way to do it, and 
>> so it's actually faster to do
>>
>> 	git ls-files -o | git update-index --add --stdin
>> 	git commit -a
>>
>> instead...
>
> Is it still the case after the fix in rc4?  Other than the
> theoretical "on multi-core, ls-files and update-index can run in
> parallel" performance boost potential,

When I did my apprenticeship, one thing I learnt was that to
accomplish a repetitive task comprised of several steps, you organize
it in a way that does not require you to change the tool you are
holding/using until you have finished using it.

What's good for the user is good for the computer: even on single core
systems, working off a complete pipeline buffer before switching
context again will help keeping disk positioning and cache poisoning
down.  However, it will depend on the scheduler: if it never allows
pipes to even slighly fill up (which has been the normal behavior of
the Linux scheduler for years in spite of complaints I voiced several
times), you don't get the advantages from this sort of processing.
CFS could conceivably help in many use cases since then the context
switch depends on more than just "pipe has some minimal content?"
which is pretty much the worst choice for context switches in batch
processing.  However, as long as we are talking buffered I/O (FILE*
and block buffering), we are losing some parallelism potential and
gaining some blocking advantage.

quoted text
> I thought the fixed "git-add ." would be the same...

Possibly.  After all, there _is_ overhead associated with pipes, and
currently released kernels' scheduling behavior reaps no cache
poisoning gains.  Whatever.  I think I'll do a large test.
Speculation is not everything.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html