mirror of
https://github.com/git/git
synced 2024-10-02 14:45:21 +00:00
c9af708b1a
In the original implementation of want_object_in_pack(), we
always looked for the object in every pack, so the order did
not matter for performance.
As of the last few patches, however, we can now often break
out of the loop early after finding the first instance, and
avoid looking in the other packs at all. In this case, pack
order can make a big difference, because we'd like to find
the objects by looking at as few packs as possible.
This patch switches us to the same packed_git_mru list that
is now used by normal object lookups.
Here are timings for p5303 on linux.git:
Test HEAD^ HEAD
------------------------------------------------------------------------
5303.3: rev-list (1) 31.31(31.07+0.23) 31.28(31.00+0.27) -0.1%
5303.4: repack (1) 40.35(38.84+2.60) 40.53(39.31+2.32) +0.4%
5303.6: rev-list (50) 31.37(31.15+0.21) 31.41(31.16+0.24) +0.1%
5303.7: repack (50) 58.25(68.54+2.03) 47.28(57.66+1.89) -18.8%
5303.9: rev-list (1000) 31.91(31.57+0.33) 31.93(31.64+0.28) +0.1%
5303.10: repack (1000) 304.80(376.00+3.92) 87.21(159.54+2.84) -71.4%
The rev-list numbers are unchanged, which makes sense (they
are not exercising this code at all). The 50- and 1000-pack
repack cases show considerable improvement.
The single-pack repack case doesn't, of course; there's
nothing to improve. In fact, it gives us a baseline for how
fast we could possibly go. You can see that though rev-list
can approach the single-pack case even with 1000 packs,
repack doesn't. The reason is simple: the loop we are
optimizing is only part of what the repack is doing. After
the "counting" phase, we do delta compression, which is much
more expensive when there are multiple packs, because we
have fewer deltas we can reuse (you can also see that these
numbers come from a multicore machine; the CPU times are
much higher than the wall-clock times due to the delta
phase).
So the good news is that in cases with many packs, we used
to be dominated by the "counting" phase, and now we are
dominated by the delta compression (which is faster, and
which we have already parallelized).
Here are similar numbers for git.git:
Test HEAD^ HEAD
---------------------------------------------------------------------
5303.3: rev-list (1) 1.55(1.51+0.02) 1.54(1.53+0.00) -0.6%
5303.4: repack (1) 1.82(1.80+0.08) 1.82(1.78+0.09) +0.0%
5303.6: rev-list (50) 1.58(1.57+0.00) 1.58(1.56+0.01) +0.0%
5303.7: repack (50) 2.50(3.12+0.07) 2.31(2.95+0.06) -7.6%
5303.9: rev-list (1000) 2.22(2.20+0.02) 2.23(2.19+0.03) +0.5%
5303.10: repack (1000) 10.47(16.78+0.22) 7.50(13.76+0.22) -28.4%
Not as impressive in terms of percentage, but still
measurable wins. If you look at the wall-clock time
improvements in the 1000-pack case, you can see that linux
improved by roughly 10x as many seconds as git. That's
because it has roughly 10x as many objects, and we'd expect
this improvement to scale linearly with the number of
objects (since the number of packs is kept constant). It's
just that the "counting" phase is a smaller percentage of
the total time spent for a git.git repack, and hence the
percentage win is smaller.
The implementation itself is a straightforward use of the
MRU code. We only bother marking a pack as used when we know
that we are able to break early out of the loop, for two
reasons:
1. If we can't break out early, it does no good; we have
to visit each pack anyway, so we might as well avoid
even the minor overhead of managing the cache order.
2. The mru_mark() function reorders the list, which would
screw up our traversal. So it is only safe to mark when
we are about to break out of the loop. We could record
the found pack and mark it after the loop finishes, of
course, but that's more complicated and it doesn't buy
us anything due to (1).
Note that this reordering does have a potential impact on
the final pack, as we store only a single "found" pack for
each object, even if it is present in multiple packs. In
principle, any copy is acceptable, as they all refer to the
same content. But in practice, they may differ in whether
they are stored as deltas, against which base, etc. This may
have an impact on delta reuse, and even the delta search
(since we skip pairs that were already in the same pack).
It's not clear whether this change of order would hurt or
even help average cases, though. The most likely reason to
have duplicate objects is from the completion of thin packs
(e.g., you have some objects in a "base" pack, then receive
several pushes; the packs you receive may be thin on the
wire, with deltas that refer to bases outside the pack, but
we complete them with duplicate base objects when indexing
them).
In such a case the current code would always find the thin
duplicates (because we currently walk the packs in reverse
chronological order). Whereas with this patch, some of those
duplicates would be found in the base pack instead.
In my tests repacking a real-world case of linux.git with
3600 thin-pack pushes (on top of a large "base" pack), the
resulting pack was about 0.04% larger with this patch. On
the other hand, because we were more likely to hit the base
pack, there were more opportunities for delta reuse, and we
had 50,000 fewer objects to examine in the delta search.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
||
|---|---|---|
| block-sha1 | ||
| builtin | ||
| ci | ||
| compat | ||
| contrib | ||
| Documentation | ||
| ewah | ||
| git-gui | ||
| gitk-git | ||
| gitweb | ||
| mergetools | ||
| perl | ||
| po | ||
| ppc | ||
| refs | ||
| t | ||
| templates | ||
| vcs-svn | ||
| xdiff | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .travis.yml | ||
| abspath.c | ||
| aclocal.m4 | ||
| advice.c | ||
| advice.h | ||
| alias.c | ||
| alloc.c | ||
| archive-tar.c | ||
| archive-zip.c | ||
| archive.c | ||
| archive.h | ||
| argv-array.c | ||
| argv-array.h | ||
| attr.c | ||
| attr.h | ||
| base85.c | ||
| bisect.c | ||
| bisect.h | ||
| blob.c | ||
| blob.h | ||
| branch.c | ||
| branch.h | ||
| builtin.h | ||
| bulk-checkin.c | ||
| bulk-checkin.h | ||
| bundle.c | ||
| bundle.h | ||
| cache-tree.c | ||
| cache-tree.h | ||
| cache.h | ||
| check-builtins.sh | ||
| check-racy.c | ||
| check_bindir | ||
| color.c | ||
| color.h | ||
| column.c | ||
| column.h | ||
| combine-diff.c | ||
| command-list.txt | ||
| commit-slab.h | ||
| commit.c | ||
| commit.h | ||
| common-main.c | ||
| config.c | ||
| config.mak.in | ||
| config.mak.uname | ||
| configure.ac | ||
| connect.c | ||
| connect.h | ||
| connected.c | ||
| connected.h | ||
| convert.c | ||
| convert.h | ||
| copy.c | ||
| COPYING | ||
| credential-cache--daemon.c | ||
| credential-cache.c | ||
| credential-store.c | ||
| credential.c | ||
| credential.h | ||
| csum-file.c | ||
| csum-file.h | ||
| ctype.c | ||
| daemon.c | ||
| date.c | ||
| decorate.c | ||
| decorate.h | ||
| delta.h | ||
| diff-delta.c | ||
| diff-lib.c | ||
| diff-no-index.c | ||
| diff.c | ||
| diff.h | ||
| diffcore-break.c | ||
| diffcore-delta.c | ||
| diffcore-order.c | ||
| diffcore-pickaxe.c | ||
| diffcore-rename.c | ||
| diffcore.h | ||
| dir.c | ||
| dir.h | ||
| editor.c | ||
| entry.c | ||
| environment.c | ||
| exec_cmd.c | ||
| exec_cmd.h | ||
| fast-import.c | ||
| fetch-pack.c | ||
| fetch-pack.h | ||
| fmt-merge-msg.h | ||
| fsck.c | ||
| fsck.h | ||
| generate-cmdlist.sh | ||
| gettext.c | ||
| gettext.h | ||
| git-add--interactive.perl | ||
| git-archimport.perl | ||
| git-bisect.sh | ||
| git-compat-util.h | ||
| git-cvsexportcommit.perl | ||
| git-cvsimport.perl | ||
| git-cvsserver.perl | ||
| git-difftool--helper.sh | ||
| git-difftool.perl | ||
| git-filter-branch.sh | ||
| git-instaweb.sh | ||
| git-merge-octopus.sh | ||
| git-merge-one-file.sh | ||
| git-merge-resolve.sh | ||
| git-mergetool--lib.sh | ||
| git-mergetool.sh | ||
| git-p4.py | ||
| git-parse-remote.sh | ||
| git-quiltimport.sh | ||
| git-rebase--am.sh | ||
| git-rebase--interactive.sh | ||
| git-rebase--merge.sh | ||
| git-rebase.sh | ||
| git-relink.perl | ||
| git-remote-testgit.sh | ||
| git-request-pull.sh | ||
| git-send-email.perl | ||
| git-sh-i18n.sh | ||
| git-sh-setup.sh | ||
| git-stash.sh | ||
| git-submodule.sh | ||
| git-svn.perl | ||
| GIT-VERSION-GEN | ||
| git-web--browse.sh | ||
| git.c | ||
| git.rc | ||
| gpg-interface.c | ||
| gpg-interface.h | ||
| graph.c | ||
| graph.h | ||
| grep.c | ||
| grep.h | ||
| hashmap.c | ||
| hashmap.h | ||
| help.c | ||
| help.h | ||
| hex.c | ||
| http-backend.c | ||
| http-fetch.c | ||
| http-push.c | ||
| http-walker.c | ||
| http.c | ||
| http.h | ||
| ident.c | ||
| imap-send.c | ||
| INSTALL | ||
| khash.h | ||
| kwset.c | ||
| kwset.h | ||
| levenshtein.c | ||
| levenshtein.h | ||
| LGPL-2.1 | ||
| line-log.c | ||
| line-log.h | ||
| line-range.c | ||
| line-range.h | ||
| list-objects.c | ||
| list-objects.h | ||
| ll-merge.c | ||
| ll-merge.h | ||
| lockfile.c | ||
| lockfile.h | ||
| log-tree.c | ||
| log-tree.h | ||
| mailinfo.c | ||
| mailinfo.h | ||
| mailmap.c | ||
| mailmap.h | ||
| Makefile | ||
| match-trees.c | ||
| merge-blobs.c | ||
| merge-blobs.h | ||
| merge-recursive.c | ||
| merge-recursive.h | ||
| merge.c | ||
| mergesort.c | ||
| mergesort.h | ||
| mru.c | ||
| mru.h | ||
| name-hash.c | ||
| notes-cache.c | ||
| notes-cache.h | ||
| notes-merge.c | ||
| notes-merge.h | ||
| notes-utils.c | ||
| notes-utils.h | ||
| notes.c | ||
| notes.h | ||
| object.c | ||
| object.h | ||
| pack-bitmap-write.c | ||
| pack-bitmap.c | ||
| pack-bitmap.h | ||
| pack-check.c | ||
| pack-objects.c | ||
| pack-objects.h | ||
| pack-revindex.c | ||
| pack-revindex.h | ||
| pack-write.c | ||
| pack.h | ||
| pager.c | ||
| parse-options-cb.c | ||
| parse-options.c | ||
| parse-options.h | ||
| patch-delta.c | ||
| patch-ids.c | ||
| patch-ids.h | ||
| path.c | ||
| pathspec.c | ||
| pathspec.h | ||
| pkt-line.c | ||
| pkt-line.h | ||
| preload-index.c | ||
| pretty.c | ||
| prio-queue.c | ||
| prio-queue.h | ||
| progress.c | ||
| progress.h | ||
| prompt.c | ||
| prompt.h | ||
| quote.c | ||
| quote.h | ||
| reachable.c | ||
| reachable.h | ||
| read-cache.c | ||
| README.md | ||
| ref-filter.c | ||
| ref-filter.h | ||
| reflog-walk.c | ||
| reflog-walk.h | ||
| refs.c | ||
| refs.h | ||
| RelNotes | ||
| remote-curl.c | ||
| remote-testsvn.c | ||
| remote.c | ||
| remote.h | ||
| replace_object.c | ||
| rerere.c | ||
| rerere.h | ||
| resolve-undo.c | ||
| resolve-undo.h | ||
| revision.c | ||
| revision.h | ||
| run-command.c | ||
| run-command.h | ||
| send-pack.c | ||
| send-pack.h | ||
| sequencer.c | ||
| sequencer.h | ||
| server-info.c | ||
| setup.c | ||
| sh-i18n--envsubst.c | ||
| sha1-array.c | ||
| sha1-array.h | ||
| sha1-lookup.c | ||
| sha1-lookup.h | ||
| sha1_file.c | ||
| sha1_name.c | ||
| shallow.c | ||
| shell.c | ||
| shortlog.h | ||
| show-index.c | ||
| sideband.c | ||
| sideband.h | ||
| sigchain.c | ||
| sigchain.h | ||
| split-index.c | ||
| split-index.h | ||
| strbuf.c | ||
| strbuf.h | ||
| streaming.c | ||
| streaming.h | ||
| string-list.c | ||
| string-list.h | ||
| submodule-config.c | ||
| submodule-config.h | ||
| submodule.c | ||
| submodule.h | ||
| symlinks.c | ||
| tag.c | ||
| tag.h | ||
| tar.h | ||
| tempfile.c | ||
| tempfile.h | ||
| thread-utils.c | ||
| thread-utils.h | ||
| trace.c | ||
| trace.h | ||
| trailer.c | ||
| trailer.h | ||
| transport-helper.c | ||
| transport.c | ||
| transport.h | ||
| tree-diff.c | ||
| tree-walk.c | ||
| tree-walk.h | ||
| tree.c | ||
| tree.h | ||
| unicode_width.h | ||
| unimplemented.sh | ||
| unix-socket.c | ||
| unix-socket.h | ||
| unpack-trees.c | ||
| unpack-trees.h | ||
| update_unicode.sh | ||
| upload-pack.c | ||
| url.c | ||
| url.h | ||
| urlmatch.c | ||
| urlmatch.h | ||
| usage.c | ||
| userdiff.c | ||
| userdiff.h | ||
| utf8.c | ||
| utf8.h | ||
| varint.c | ||
| varint.h | ||
| version.c | ||
| version.h | ||
| versioncmp.c | ||
| walker.c | ||
| walker.h | ||
| wildmatch.c | ||
| wildmatch.h | ||
| worktree.c | ||
| worktree.h | ||
| wrap-for-bin.sh | ||
| wrapper.c | ||
| write_or_die.c | ||
| ws.c | ||
| wt-status.c | ||
| wt-status.h | ||
| xdiff-interface.c | ||
| xdiff-interface.h | ||
| zlib.c | ||
Git - fast, scalable, distributed revision control system
Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals.
Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2). It was originally written by Linus Torvalds with help of a group of hackers around the net.
Please read the file INSTALL for installation instructions.
Many Git online resources are accessible from http://git-scm.com/ including full documentation and Git related tools.
See Documentation/gittutorial.txt to get started, then see
Documentation/giteveryday.txt for a useful minimum set of commands, and
Documentation/git-.txt for documentation of each command.
If git has been correctly installed, then the tutorial can also be
read with man gittutorial or git help tutorial, and the
documentation of each command with man git-<commandname> or git help <commandname>.
CVS users may also want to read Documentation/gitcvs-migration.txt
(man gitcvs-migration or git help cvs-migration if git is
installed).
The user discussion and development of Git take place on the Git mailing list -- everyone is welcome to post bug reports, feature requests, comments and patches to git@vger.kernel.org (read Documentation/SubmittingPatches for instructions on patch submission). To subscribe to the list, send an email with just "subscribe git" in the body to majordomo@vger.kernel.org. The mailing list archives are available at http://news.gmane.org/gmane.comp.version-control.git/, http://marc.info/?l=git and other archival sites.
The maintainer frequently sends the "What's cooking" reports that list the current status of various development topics to the mailing list. The discussion following them give a good reference for project status, development direction and remaining tasks.
The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your mood):
- random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
- "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks