git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "R. Tyler Ballance" <tyler@slide.com>
To: Toan Pham <tpham3783@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Big project, slow access!
Date: Fri, 18 Sep 2009 14:32:16 -0700	[thread overview]
Message-ID: <20090918213216.GJ18785@starfruit.corp.slide.com> (raw)
In-Reply-To: <ffb2c0280909181138r7fde8722n80be4bdf95864c37@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]


On Fri, 18 Sep 2009, Toan Pham wrote:

> Hi,
> 
> I use git to maintain a project that is at least 8 gigs in size.
> The project is a Linux from Scratch repository that includes source
> codes to approximately 2000 open source projects,
> gcc tool-chain, 1000+ configurations for different software packages,
> source code for different kernel versions,
> and many linux distributions/flavors resulted from this LFS build environment.
> 
> The git's object repository is now 4.6 gigs and consists of approx.
> 610,000 files and folders.
> The speed of git is now terribly slow.  Each time I use basic commands
> like 'git status' or 'git diff',
> it would take at least 5 minutes for git to give me back a result.
> Again, the machine that i run git on is a P4 3.2 gig-hertz with HT.

Howdy Toan, we have a similarly large repository ~405k files, the .git
folder fully packed is ~6GB. 

The advise to fully-pack your repository is likely going to have the
greatest impact on your performance in the short term, in the long term
however you might want to consider using git-filter-branch(1) or other
tools available to separate our the components of your current Git
reposotory into a series of repos.

The performance hit you're seeing likely has nothing to do with your
processor speed either, but rather your disk search speed (i'm waiting
for a new fancy SSD to help alleviate my issues ;))

> would  someone please recommend on how i can optimize git's performance?
> Git is so slow, are there better ways to manage a project like this?

Rethink how your project is laid out, and whether certain binaries files
need to sit in the tree, or can be build on a need-by-need basis.



Cheers
-R. Tyler Ballance
Slide, Inc.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

  parent reply	other threads:[~2009-09-18 21:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-18 18:38 Big project, slow access! Toan Pham
2009-09-18 19:02 ` Nicolas Pitre
2009-09-18 19:05 ` Thiago Farina
2009-09-18 20:19   ` Nicolas Pitre
2009-09-18 21:32 ` R. Tyler Ballance [this message]
2009-09-22 14:51   ` Toan Pham
2009-09-22 15:22     ` R. Tyler Ballance

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=20090918213216.GJ18785@starfruit.corp.slide.com \
    --to=tyler@slide.com \
    --cc=git@vger.kernel.org \
    --cc=tpham3783@gmail.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).