Re: [StGit PATCH] Convert "sink" to the new infrastructure
- From
- Catalin Marinas <catalin.marinas@gmail.com>
- Date
- Sep 17, 2008, 11:55 UTC
- Message-ID
- <b0943d9e0809170455m53eaf677t87e9ade3f001d044@mail.gmail.com>
- In-Reply-To
- <20080916193647.GA12513@diana.vm.bytemark.co.uk>
2008/9/16 Karl Hasselström <kha@treskal.com>:
Show 12 quoted lines
> 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.
Show 11 quoted lines
>> 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 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