Junio C Hamano <gitster@xxxxxxxxx> writes: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
