Dear diary, on Sun, Apr 10, 2005 at 07:45:12PM CEST, I got a letter
where Ingo Molnar <[EMAIL PROTECTED]> told me that...
>
> * Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
> > > > I will also need to do more testing on the linux kernel tree.
> > > > Committing patch-2.6.7 on 2.6.6 kernel and then diffing results in
> > > >
> > > > $ time gitdiff.sh `parent-id` `tree-id` >p
> > > > real 5m37.434s
> > > > user 1m27.113s
> > > > sys 2m41.036s
> > > >
> > > > which is pretty horrible, it seems to me. Any benchmarking help is of
> > > > course welcomed, as well as any other feedback.
> > >
> > > it seems from the numbers that your system doesnt have enough RAM for
> > > this and is getting IO-bound?
> >
> > Not the only problem, without I/O, he will go down to 4m8s (u+s) which
> > is still in the same order of magnitude.
>
> probably not the only problem - but if we are lucky then his system was
> just trashing within the kernel repository and then most of the overhead
> is the _unnecessary_ IO that happened due to that (which causes CPU
> overhead just as much). The dominant system time suggests so, to a
> certain degree. Maybe this is wishful thinking.
It turns out to be the forks for doing all the cuts and such what is
bogging it down so awfully (doing diff-tree takes 0.48s ;-). I do about
15 forks per change, I guess, and for some reason cut takes a long of
time on its own.
I've rewritten the cuts with the use of bash arrays and other smart
stuff. I somehow don't feel comfortable using this and prefer the
old-fashioned ways, but it would be plain unusable without this.
Now I'm down to
real 1m21.440s
user 0m32.374s
sys 0m42.200s
and I kinda doubt if it is possible to cut this much down. Almost no
disk activity, I have almost everything cached by now, apparently.
Anyway, you can git pull to get the optimized version.
Thanks for the help,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
