Improving git-status on OSX.

[Scott Hess]

If you're like me, you say "git status" about a thousand times per day.  With the recent repo merge, I found it frequently was very slow, often up to 40 seconds, even on a beefy machine with SSD.  Debugging it leads me to believe it's mostly lstat() calls.

This seems to increase the cache backing the info lstat references:

  sudo sysctl kern.maxvnodes=$((512*1024))

The default setting is 263168 (257*1024).  Running git-status after reboot sends kern.num_vnodes from ~21k directly to the max of 263168.  After the above change to increase the max kern.num_vnodes will go a bit higher but then be more stable.

To make it take effect after reboot:

  echo kern.maxvnodes=$((512*1024)) | sudo tee -a /etc/sysctl.conf

Or edit the file, of course.

My understanding is that the default setting is derived from amount of physical memory, but I get 263168 on both 16GB machines and 64GB machines, so maybe it gets capped.  I expect it to be safe enough to set it even higher than this, but it probably only makes sense to do so if you routinely bounce between multiple repos (I have such a setup via git-new-workdir).

If you are running git 2.6 or higher, this might also help, by reducing the number of lstat calls required in the first place:

   git update-index --untracked-cache

http://crbug.com/535746

-scott

[Levi Weintraub]

+1

Slow git status/diff/whatever was driving me crazy on Mac. Making this change on my Mac desktop and Laptop made things far more usable.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Mike Pinkerton]

Can you update the public build/workflow instructions to mention this?

--

Mike Pinkerton
Mac Weenie
pink...@google.com

[Lucas]

Thanks to y'all a year for documenting this last year. :-)

Even running with 512K maxvnodes, I'm still getting 3 seconds per `git status` on a beefy laptop (with a warm cache).

Should I be satisfied with that, or is there some other common pitfall I should check up on?

(I tried increasing to 2M maxvnodes, but that didn't make a significant difference.)

»Lucas

On Wednesday, October 21, 2015 at 3:21:29 PM UTC-7, Mike Pinkerton wrote:

Can you update the public build/workflow instructions to mention this?

On Wed, Oct 21, 2015 at 2:02 PM, Levi Weintraub <le...@chromium.org> wrote:

+1

Slow git status/diff/whatever was driving me crazy on Mac. Making this change on my Mac desktop and Laptop made things far more usable.

On Wed, Oct 21, 2015 at 1:39 PM, Scott Hess <sh...@chromium.org> wrote:

If you're like me, you say "git status" about a thousand times per day.  With the recent repo merge, I found it frequently was very slow, often up to 40 seconds, even on a beefy machine with SSD.  Debugging it leads me to believe it's mostly lstat() calls.

This seems to increase the cache backing the info lstat references:

  sudo sysctl kern.maxvnodes=$((512*1024))

The default setting is 263168 (257*1024).  Running git-status after reboot sends kern.num_vnodes from ~21k directly to the max of 263168.  After the above change to increase the max kern.num_vnodes will go a bit higher but then be more stable.

To make it take effect after reboot:

  echo kern.maxvnodes=$((512*1024)) | sudo tee -a /etc/sysctl.conf

Or edit the file, of course.

My understanding is that the default setting is derived from amount of physical memory, but I get 263168 on both 16GB machines and 64GB machines, so maybe it gets capped.  I expect it to be safe enough to set it even higher than this, but it probably only makes sense to do so if you routinely bounce between multiple repos (I have such a setup via git-new-workdir).

If you are running git 2.6 or higher, this might also help, by reducing the number of lstat calls required in the first place:

   git update-index --untracked-cache

http://crbug.com/535746

-scott

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Scott Hess]

If: sudo sysctl kern.num_vnodes
and: sud sysctl kern.maxvnodes
are the same, then increasing the setting may be worthwhile. Though
num_vnodes never decreases, this test makes more sense just after
startup.

I was OOO today, so pretty cold cache, my timings are:

time git status
real 0m41.548s
user 0m1.091s
sys 2m23.416s

then:
real 0m5.029s
user 0m0.896s
sys 0m3.173s

So I'm thinking your 3s runtime is probably as good as you'll see. It
was the 41s version that my hack was addressing.

[Versus <1s on Linux, sigh.]

-scott

>>>> an email to chromium-dev...@chromium.org.

[Bruce]

On Windows (Z840, SSD) I see git status taking ~1.3 s with --no-untracked-cache and 2.0 s with --untracked-cache

That surprised me. I didn't expect --untracked-cache to be a pessimization on Windows, but the results are pretty consistent. I also didn't expect Windows to be faster than OSX!

>>>> an email to chromium-dev+unsubscribe@chromium.org.

[Elliott Sprehn]

On Wed, Aug 31, 2016 at 2:34 PM, Bruce <bruce...@chromium.org> wrote:

On Windows (Z840, SSD) I see git status taking ~1.3 s with --no-untracked-cache and 2.0 s with --untracked-cache

That surprised me. I didn't expect --untracked-cache to be a pessimization on Windows, but the results are pretty consistent. I also didn't expect Windows to be faster than OSX!

That probably depends on your hardware. :)