From: Jakub Narebski <jnareb@gmail.com>
To: John <john@puckerupgames.com>
Cc: git@vger.kernel.org
Subject: Re: serious performance issues with images, audio files, and other "non-code" data
Date: Wed, 12 May 2010 12:15:41 -0700 (PDT) [thread overview]
Message-ID: <m339xxdj71.fsf@localhost.localdomain> (raw)
In-Reply-To: <4BEAF941.6040609@puckerupgames.com>
John <john@puckerupgames.com> writes:
> We're seeing serious performance issues with repos that store media
> files, even relatively small files. For example, a web site with less
> than 100 MB of images can take minutes to commit, push, or pull when
> images have changed.
>
> Our first guess was that git is repeatedly attempting to
> compress/decompress data that had already been compressed. We tried
> these configuration settings (shooting in the dark) to no avail:
>
> core.compression 0 ## Docs say this disables compression. Didn't seem to work.
> pack.depth 1 ## Unclear what this does.
> pack.window 0 ## No idea what this does.
> gc.auto 0 ## We hope this disables automatic packing.
>
> Our guess that re-compression is to blame may not even be valid since
> we can manually re-compress these files in seconds, not minutes.
>
> Is there a trick to getting git to simply "copy files as is"? In
> other words, don't attempt to compress them, don't attempt to "diff"
> them, just store/copy/transfer the files as-is?
Search for `delta` attribute, which should be unset for files that you
don't want for git to attempt (binary) delta against, in gitattributes
manpage.
P.S. There is also git-bigfiles project that migth be of interest to
you.
--
Jakub Narebski
Poland
ShadeHawk on #git
next prev parent reply other threads:[~2010-05-12 19:22 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-12 18:53 serious performance issues with images, audio files, and other "non-code" data John
2010-05-12 19:15 ` Jakub Narebski [this message]
2010-05-14 5:10 ` Jeff King
2010-05-14 12:54 ` John
2010-05-14 17:26 ` Dirk Süsserott
2010-05-17 23:16 ` Jeff King
2010-05-17 23:33 ` Sverre Rabbelier
2010-05-18 19:07 ` Jeff King
2010-05-18 19:10 ` Sverre Rabbelier
2010-05-18 19:27 ` Jeff King
2010-05-18 19:37 ` Nicolas Pitre
2010-05-18 18:50 ` John
2010-05-18 18:54 ` Sverre Rabbelier
2010-05-18 19:19 ` Jeff King
2010-05-18 19:33 ` Nicolas Pitre
2010-05-18 19:41 ` Jeff King
2010-05-18 19:59 ` Nicolas Pitre
2010-05-24 0:21 ` John
2010-05-24 1:16 ` Junio C Hamano
2010-05-24 7:01 ` John
2010-05-25 6:33 ` Jeff King
2010-05-25 7:28 ` Michael J Gruber
2010-05-25 16:12 ` John
2010-05-25 17:18 ` Nicolas Pitre
2010-05-25 17:47 ` John
2010-05-24 5:39 ` Jeff King
2010-05-24 6:44 ` John
2010-05-24 6:45 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m339xxdj71.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=john@puckerupgames.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).