From: "Catalin Marinas" <catalin.marinas@gmail.com>
To: "Karl Hasselström" <kha@treskal.com>
Cc: git@vger.kernel.org
Subject: Re: [StGit PATCH] Convert "sink" to the new infrastructure
Date: Wed, 17 Sep 2008 12:55:39 +0100 [thread overview]
Message-ID: <b0943d9e0809170455m53eaf677t87e9ade3f001d044@mail.gmail.com> (raw)
In-Reply-To: <20080916193647.GA12513@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2116 bytes --]
2008/9/16 Karl Hasselström <kha@treskal.com>:
> On 2008-09-16 15:59:31 +0100, Catalin Marinas wrote:
>> I think we could merge your experimental branch into master. I gave
>> it a try and seems OK. The only issue I had was that I had an older
>> version of Git and it failed in really weird ways (stg pop still
>> busy-looping after 4 minutes and in another case it failed with
>> broken pipe). Once I pulled the latest Git, it was fine but we
>> should try to be compatible at least with the Git version in the
>> Debian testing distribution. It might be the patch at the top with
>> diff-ing several trees at once but I haven't checked.
>
> There are two patches that depend on new git versions. One needs git
> 1.5.6, which is in testing so I'll be pushing that to you;
OK.
> the other
> needs Junio's master branch, and i won't even consider asking you to
> take it until it's in a released git.
Correct :-)
> I hope to push it out to you tonight or tomorrow, but I have a small
> pet patch I'd like to finish first, so I might be late.
OK, no problem. I won't have much time before the weekend anyway.
>> BTW, I ran some benchmarks on stable/master/kha-experimental
>> branches with 300 patches from the 2.6.27-rc5-mm1 kernel. See
>> attached for the results. Since performance was my worry with the
>> stack log stuff, it turns out that there isn't a big difference with
>> real patches. I think pushing can be made even faster by trying a
>> git-apply first and taking the diff from the saved blobs in the log.
>
> When benchmarking recent StGits, you'll want to try goto as well,
> since push and pop are not yet new-infrastructure-ized (meaning
> they're getting slowdowns from the stack log, but no speedups (if any)
> from the new infrastructure).
Indeed, goto is faster even than the stable branch. I attached the new
figures. I think it could go even faster if pushing attempts a "git
apply" first before the index merge. With the stack log, the patch
diff should be saved already so no need for a "git diff" (as in the
stable branch).
--
Catalin
[-- Attachment #2: stack-log-benchmarks.txt --]
[-- Type: text/plain, Size: 1474 bytes --]
CPU: Intel Pentium 4 @ 2.5GHz
Memory: 1GB
2.6.27-rc5-mm1 kernel, 300 patches uncommitted
pop/push ran a few times to heat the caches before running the
benchmarks.
Stable stgit (v0.14.3 + some fixes)
$ time stg pop -a
real 0m1.775s
user 0m0.956s
sys 0m0.724s
$ time stg push -a (fast-forward)
real 0m5.001s
user 0m1.844s
sys 0m2.860s
$ time stg push -a (no fast-forward)
real 1m27.133s
user 0m36.998s
sys 0m34.894s
$ time stg goto top-patch (fast-forward)
real 0m5.314s
user 0m1.920s
sys 0m2.768s
$ time stg goto top-patch (no fast-forward)
real 1m39.040s
user 0m37.022s
sys 0m35.666s
Current stgit master (no stack log):
$ time stg pop -a
real 0m1.621s
user 0m0.820s
sys 0m0.688s
$ time stg push -a (fast-forward)
real 0m27.205s
user 0m8.741s
sys 0m16.849s
$ time stg push -a (no fast-forward)
real 2m8.209s
user 0m46.031s
sys 0m57.260s
$ time stg goto top-patch (fast-forward)
real 0m10.437s
user 0m2.160s
sys 0m2.464s
$ time stg goto top-patch (no fast-forward)
real 1m23.244s
user 0m38.158s
sys 0m36.086s
kha/experimantal stgit (with stack log):
$ time stg pop -a
real 0m2.419s
user 0m1.144s
sys 0m1.132s
$ time stg push -a (fast-forward)
real 0m29.594s
user 0m9.217s
sys 0m17.145s
$ time stg push -a (no fast-forward)
real 2m10.270s
user 0m50.919s
sys 1m2.088s
$ time stg goto top-patch (fast-forward)
real 0m2.170s
user 0m1.084s
sys 0m0.460s
$ time stg goto top-patch (no fast-forward)
real 1m18.271s
user 0m39.026s
sys 0m31.938s
next prev parent reply other threads:[~2008-09-17 11:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-12 22:01 [StGit PATCH] Convert "sink" to the new infrastructure Catalin Marinas
2008-09-14 8:51 ` Karl Hasselström
2008-09-14 21:19 ` Catalin Marinas
2008-09-15 7:57 ` Karl Hasselström
2008-09-15 16:44 ` Catalin Marinas
2008-09-16 7:40 ` Karl Hasselström
2008-09-16 14:59 ` Catalin Marinas
2008-09-16 19:36 ` Karl Hasselström
2008-09-17 11:55 ` Catalin Marinas [this message]
2008-09-17 13:04 ` Karl Hasselström
2008-09-17 13:09 ` Karl Hasselström
2008-09-17 16:01 ` Catalin Marinas
2008-09-18 7:10 ` Karl Hasselström
2008-09-18 11:24 ` Catalin Marinas
2008-09-17 16:09 ` Catalin Marinas
2008-09-18 7:24 ` Karl Hasselström
2008-09-18 11:31 ` Catalin Marinas
2008-09-18 15:47 ` Karl Hasselström
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=b0943d9e0809170455m53eaf677t87e9ade3f001d044@mail.gmail.com \
--to=catalin.marinas@gmail.com \
--cc=git@vger.kernel.org \
--cc=kha@treskal.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).