From: Jeff Garzik <jgarzik@pobox.com>
To: Larry McVoy <lm@bitmover.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: A simple request (was Re: boring BK stats)
Date: Thu, 10 Oct 2002 10:40:25 -0400 [thread overview]
Message-ID: <3DA59159.3070901@pobox.com> (raw)
In-Reply-To: 20021010072818.F27122@work.bitmover.com
Larry McVoy wrote:
>>The laptop has 200MB RAM, and mozilla and a ton of xterms loaded. IDE
>>drives w/ Intel PIIX4 controller. The Dual Athlon has 512MB RAM, and I
>>forget what kind of IDE controller -- I think AMD. IDE drives as well.
>>
>>BitKeeper must scan the entire tree when doing a checkin or checkout, so
>>that is impossible to optimize at the SCM level without compromising
>>features... if your source tree takes up ~190MB on disk, you have 200MB
>>of RAM total, and you need to sequentially scan the entire thing, there
>>is nothing that can be done at either the OS or app level... You're just
>>screwed. Things are extremely fast on the Dual Athlon because the
>>entire tree is in RAM.
>
>
> In low memory situations you really want to run the tree compressed.
> ON a fast machine do a "bk -r admin -Z" and then clone that onto your
> laptop. I think that will drop the tree to about 145MB which will
> help, maybe. I suspect that you use enough of the rest of your 200MB
> that it still won't fit.
Yeah, I don't think that will help at all, given that X and KDE and all
its acoutrements are loaded... I would rather run uncompressed anyway :)
> For the checkouts, always do a "bk -r get -S" the -S doesn't check out the
> file again if it is already there. We could make that the default but
> it is an interface change. A fairly minor one though.
I do "bk -r co -Sq", is the above faster than that?
> We've got some other fixes in the pipeline for the checkin and integrity
> check pass.
>
> There is only so much we can do when you are trying to cram 10 pounds of
> crap in a 5 pound bag :(
indeed :) That's why I keep repeating that it's not BK's fault, and
keep pointing out that my Dual Athlon with plenty of RAM does multiple
simultaneous checks/checkins quite rapidly.
Jeff
next prev parent reply other threads:[~2002-10-10 14:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-09 23:39 A simple request (was Re: boring BK stats) Walter Landry
2002-10-10 14:14 ` Jeff Garzik
2002-10-10 14:28 ` Larry McVoy
2002-10-10 14:40 ` Jeff Garzik [this message]
2002-10-10 15:32 ` Theodore Ts'o
2002-10-11 13:35 ` Rogier Wolff
2002-10-11 14:08 ` Rogier Wolff
2002-10-11 14:14 ` Rogier Wolff
2002-10-10 22:51 ` A simple request Walter Landry
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=3DA59159.3070901@pobox.com \
--to=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lm@bitmover.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.