Re: Make the git codebase thread-safe

Am 13.02.2014 00:03, schrieb Mike Hommey:

On Wed, Feb 12, 2014 at 12:00:19PM +0100, Karsten Blees wrote:

quoted

Am 12.02.2014 04:43, schrieb Duy Nguyen:

quoted

On Wed, Feb 12, 2014 at 9:02 AM, Robin H. Johnson [off-list ref] wrote:

quoted

On Tue, Feb 11, 2014 at 05:54:51PM -0800,  Stefan Zager wrote:

quoted

We in the chromium project have a keen interest in adding threading to
git in the pursuit of performance for lengthy operations (checkout,
status, blame, ...).  Our motivation comes from hitting some
performance walls when working with repositories the size of chromium
and blink:

+1 from Gentoo on performance improvements for large repos.

The main repository in the ongoing Git migration project looks to be in
the 1.5GB range (and for those that want to propose splitting it up, we
have explored that option and found it lacking), with very deep history
(but no branches of note, and very few tags).

From v1.9 shallow clone should work for all push/pull/clone... so
history depth does not matter (on the client side). As for
gentoo-x86's large worktree, using index v4 and avoid full-tree
operations (e.g. "status .", not "status"..) should make all
operations reasonably fast. I plan to make "status" fast even without
path limiting with the help of inotify, but that's not going to be
finished soon. Did I miss anything else?

Regarding git-status on msysgit, enable core.preloadindex and core.fscache (as of 1.8.5.2).

There's no inotify on Windows, and I gave up using ReadDirectoryChangesW to
keep fscache up to date, as it _may_ report DOS file names (e.g. C:\PROGRA~1
instead of C:\Program Files).

You can use GetLongPathNameW to get the latter from the former.

Mike

Except if its a delete or rename notification...my final ReadDirectoryChangesW version cached the files by their long _and_ short names, but was so complex that it slowed most commands down rather than speeding them up :-)