Thread (51 messages) flat view 51 messages, 5 authors, 2016-06-15

Re: [StGIT PATCH] Don't use patches/<branch>/current

From: Karl Hasselström <hidden>
Date: 2016-06-15 22:43:10

On 2007-05-17 13:43:35 +0100, Catalin Marinas wrote:
I ran 'git repack -a -d' and 'git prune'. There are no other objects
apart from the generated pack:

$ du -sh .git
211M    .git

And then repeatedly 'time stg series > /dev/null':
Hmm, it seems there is a problem then. :-(
It got smaller after repacking but it is still bigger than yours.
Maybe the reason is that I have 14 branches with various patches,
some of them just for historical reasons but going back to 2.6.12.
There are also several commits generated for the patch logs.
OK. That shouldn't matter, though, since that extra history shouldn't
be examined anyway.
The CPU is a P4 at 2.5GHz and the 'stg series' operation seems to be
CPU bound rather than IO. I'm also using Python 2.3 on this PC and
for this reason I changed 2 generator constructs (x for x in ...)
with list comprehension (see the attached patch).
I don't think that's the problem, since those lists are both small.

The only possibility I can think of that might explain this is that
some of your unapplied patches are attached to a place in the commit
DAG that's far away from the branch head (e.g. you have rebased to
some entirely different place since you last had them applied), so
that "git-rev-list patch ^branch" outputs a large part of the commit
DAG.

Could you put counters in unapplied_patches() and
sort_applied_patches() to see how many lines each of them reads from
git-rev-list? The expected number (if it had taken just a little time,
like it did for me) is a small constant times the number of patches in
both cases.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help