1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
| | giteveryday(7)
==============
NAME
----
gitperformance - How to improve Git's performance
SYNOPSIS
--------
A guide to improving Git's performance beyond the defaults.
DESCRIPTION
-----------
Git is mostly performant by default, but ships with various
configuration options, command-line options, etc. that might improve
performance, but for various reasons aren't on by default.
This document provides a brief overview of these features.
The reader should not assume that turning on all of these features
will increase performance, depending on the repository, workload &
use-case turning some of them on might severely harm performance.
This document serves as a starting point for things to look into when
it comes to improving performance, not as a checklist for things to
enable or disable.
Performance by topic
--------------------
It can be hard to divide the performance features into topics, but
most of them fall into various well-defined buckets. E.g. there are
features that help with the performance of "git status", and couldn't
possibly impact repositories without working copies, and then some
that only impact the performance of cloning from a server, or help the
server itself etc.
git status
~~~~~~~~~~
Running "git status" requires traversing the working tree & comparing
it with the index. Several configuration options can help with its
performance, with some trade-offs.
- config: "core.untrackedCache=true" (see linkgit:git-config[1]) can
save on `stat(2)` calls by caching the mtime of filesystem
directories, and if they didn't change avoid recursing into that
directory to `stat(2)` every file in them.
+
pros: Can drastically speed up "git status".
+
cons: There's a speed hit for initially populating & maintaining the
cache. Doesn't work on all filesystems (see `--test-untracked-cache`
in linkgit:git-update-index[1]).
- config: "status.showUntrackedFiles=no" (see
linkgit:git-config[1]). Skips looking for files in the working tree
git doesn't already know about.
+
pros: Speeds up "git status" by making it do a lot less work.
+
cons: If there's any new & untracked files anywhere in the working
tree they won't be noticed by git. Makes it easy to accidentally miss
files to "git add" before committing, or files which might impact the
code in the working tree, but which git won't know exist.
git grep
~~~~~~~~
- config: "grep.patternType=perl" (see linkgit:git-config[1]) will use
the PCRE library when "git grep" is invoked by default. This can be
faster than POSIX regular expressions in many cases.
+
pros: Can, depending on the use-case, be faster than default "git grep".
+
cons: Can also be slower, and in some edge cases produce different
results.
- config: "grep.threads=*" (see linkgit:git-config[1] &
linkgit:git-grep[1]). Tunes the number of "git grep" worker threads.
+
pros: Giving this a more optimal value might result in a faster grep.
+
cons: It might not.
Server options to help clients
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
These features can be enabled on git servers, they won't help the
performance of the servers themselves, but will help clients that need
to talk to those servers.
- config: "repack.writeBitmaps=true" (see
linkgit:git-config[1]). Spend more time during repack to produce
bitmap index, helps clients with "fetch" & "clone" performance.
+
pros: Once enabled & run regularly as part of "git repack" speeds up
"clone" and "fetch".
+
cons: Takes extra time during repack, requires doing full
non-incremental repacks with `-A` or `-a`.
GIT
---
Part of the linkgit:git[1] suite
|