[prev in list] [next in list] [prev in thread] [next in thread]
List: fossil-dev
Subject: [fossil-dev] To R-card or not to R-card
From: Stephan Beal <sgbeal () googlemail ! com>
Date: 2014-03-15 11:52:10
Message-ID: CAKd4nAiZiaam34zgv0CELPeDXCdnEP8iRkn7qQYA+4dWDxeH2Q () mail ! gmail ! com
[Download RAW message or body]
Hi, all,
i'm looking for opinions again... libfossil can now optionally skip the
generation and validation of R-cards, and my question is: should they
default to on or off? Historically, fossil calculates the R-card as another
layer of consistency check, and it was originally required. Practice showed
that the cost of the check (lots of memory and time) was painful in very
large repos (e.g. tcl). fossil(1) accepts manifests with and without
R-cards, but always(?) generates one.
A brief example of the cost difference:
1) a checkin with the R-card for a repo with about 200 files. Valgrind
tells me: 15401 allocs using a total of 32.8MB, with peak RAM usage about
10MB, most of it in blob/buffer memory from the R-card calculation.
2) That same checkin without the R-card: 11997 allocations totaling 14.2MB
RAM, with peak of 1.5MB, the slight majority of it from sqlite3.
That was for a single-file change (though the number of changes doesn't
directly affect the R-card cost).
My intuition says to leave it enabled "because it's always been there," but
my brain tells me that it's safe to disable and the speed/memory gain is
worth it.
So, the concrete question is: should the "-r" flag to f-checkin mean
"enable R-card calculation" or "disable R-card calculation"?
:-?
(Trivia: i once ran php with an empty script through valgrind. It alloc'd
20000 times.)
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
[Attachment #3 (text/html)]
<div dir="ltr">Hi, all,<div><br></div><div>i'm looking for opinions again... \
libfossil can now optionally skip the generation and validation of R-cards, and my \
question is: should they default to on or off? Historically, fossil calculates the \
R-card as another layer of consistency check, and it was originally required. \
Practice showed that the cost of the check (lots of memory and time) was painful in \
very large repos (e.g. tcl). fossil(1) accepts manifests with and without R-cards, \
but always(?) generates one.<br clear="all"> <div><br></div><div>A brief example of \
the cost difference:</div><div><br></div><div>1) a checkin with the R-card for a repo \
with about 200 files. Valgrind tells me: 15401 allocs using a total of 32.8MB, with \
peak RAM usage about 10MB, most of it in blob/buffer memory from the R-card \
calculation.</div> <div><br></div><div>2) That same checkin without the R-card: 11997 \
allocations totaling 14.2MB RAM, with peak of 1.5MB, the slight majority of it from \
sqlite3.</div><div><br></div><div>That was for a single-file change (though the \
number of changes doesn't directly affect the R-card cost).</div> \
<div><br></div><div>My intuition says to leave it enabled "because it's \
always been there," but my brain tells me that it's safe to disable and the \
speed/memory gain is worth it.</div><div><br></div><div> So, the concrete question \
is: should the "-r" flag to f-checkin mean "enable R-card \
calculation" or "disable R-card \
calculation"?</div><div><br></div><div>:-?</div><div><br></div><div>(Trivia: i \
once ran php with an empty script through valgrind. It alloc'd 20000 \
times.)</div> <div><br></div>-- <br><div dir="ltr">----- stephan beal<br><a \
href="http://wanderinghorse.net/home/stephan/" \
target="_blank">http://wanderinghorse.net/home/stephan/</a><div><a \
href="http://gplus.to/sgbeal" target="_blank">http://gplus.to/sgbeal</a></div> \
<div>"Freedom is sloppy. But since tyranny's the only guaranteed byproduct \
of those who insist on a perfect world, freedom will have to do." -- Bigby \
Wolf</div></div> </div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic