core.fscache still useful with Git for Windows 2.x?

[Lars Schneider]

Hi,

all over the Internet [1] people suggest to set "core.fscache true" to speed up Git for Windows. Is this still true for Git for Windows 2.x?

I can't find any reference in the source code [2].

If this config is still useful. Would it hurt a Git installation on OS X or Linux?

Thanks,

Lars

[1] https://www.google.de/#safe=off&q=core.fscache

[2] https://github.com/git-for-windows/git/search?q=fscache&type=Code

[Duy Nguyen]

On Wed, Jan 6, 2016 at 6:18 PM, Lars Schneider <larsxsc...@gmail.com> wrote:
> Hi,
>
> all over the Internet [1] people suggest to set "core.fscache true" to speed
> up Git for Windows. Is this still true for Git for Windows 2.x?
> I can't find any reference in the source code [2].

It's still there [3]. I can't say if the code is still being used
though (but I think it is)

[3] https://github.com/git-for-windows/git/blob/master/compat/win32/fscache.c
--
Duy

[Johannes Schindelin]

Hi Lars,

On Wed, 6 Jan 2016, Lars Schneider wrote:

> all over the Internet [1] people suggest to set "core.fscache true" to
> speed up Git for Windows. Is this still true for Git for Windows 2.x?

It is used: there is an experimental option called

Enable file system caching

File system data will be read in bulk and cached in memory for
certain operations ("core.fscache" is set to "true"). This provides
a significant performance boost (experimental).

on the last wizard page of the installer. It is disabled by default, but I
think I am getting thoroughly convinced that we want this to be enabled by
default (I am running all of my Git operations with this flag enabled for
months now).

> I can't find any reference in the source code [2].

That's because it says

Sorry, forked repositories are not currently searchable.

;-)

Duy pointed you in the right direction.

> If this config is still useful. Would it hurt a Git installation on OS X
> or Linux?

It won't hurt OSX nor Linux because Git simply does not understand (and
hence ignores) that option there.

Ciao,
Dscho

[Lars Schneider]

On Wednesday, January 6, 2016 at 2:28:08 PM UTC+1, Johannes Schindelin wrote:

Hi Lars,

On Wed, 6 Jan 2016, Lars Schneider wrote:

> all over the Internet [1] people suggest to set "core.fscache true" to
> speed up Git for Windows. Is this still true for Git for Windows 2.x?

It is used: there is an experimental option called

        Enable file system caching

        File system data will be read in bulk and cached in memory for
        certain operations ("core.fscache" is set to "true"). This provides
        a significant performance boost (experimental).

on the last wizard page of the installer. It is disabled by default, but I
think I am getting thoroughly convinced that we want this to be enabled by
default (I am running all of my Git operations with this flag enabled for
months now).

> I can't find any reference in the source code [2].

That's because it says

        Sorry, forked repositories are not currently searchable.

;-)

Ahhhh... I should start reading the text on the screen :-)

 

Duy pointed you in the right direction.

> If this config is still useful. Would it hurt a Git installation on OS X
> or Linux?

It won't hurt OSX nor Linux because Git simply does not understand (and
hence ignores) that option there.

Thank you for the info!

Cheers,

Lars 

[Paul Smith]

On Wed, 2016-01-06 at 14:28 +0100, Johannes Schindelin wrote:
> It is used: there is an experimental option called
>
> Enable file system caching
>
> File system data will be read in bulk and cached in memory for
> certain operations ("core.fscache" is set to "true"). This provides
> a significant performance boost (experimental).
>
> on the last wizard page of the installer. It is disabled by default,
> but I think I am getting thoroughly convinced that we want this to be
> enabled by default (I am running all of my Git operations with this
> flag enabled for months now).

I was going to ask about this (thanks for the earlier response regarding
32/64 bit versions, that was very helpful!)

We have a set of Windows servers which do nothing but build our code on
Windows. So, they are constantly running "git pull" (or "git clone") on
different Git workspaces, and not working on the same workspace for
extended periods. Is anyone familiar enough with this feature to know
whether or not such use would see any benefit from enabling caching?

I'm wondering if it's caching of disk data between multiple git
operations, or if it's some way of "pre-loading" off disk so that even
single operations like "git pull" will have a performance boost.

Cheers!

[Karsten Blees]

Am 09.01.2016 um 17:02 schrieb Paul Smith:
>
> I'm wondering if it's caching of disk data between multiple git
> operations, or if it's some way of "pre-loading" off disk so that even
> single operations like "git pull" will have a performance boost.
>

It is a per process, in-memory cache of file attributes (lstat data).
IOW no cache state is stored between git.exe processes, and there is no
background process to keep track of state.

The cache improves 'git status' performance, and with 'core.preloadindex'
all git operations that read the work tree (including the merge part of
'git pull').

Cheers,
Karsten