Re: speedup allocation in pack-redundant.c

On 11/23/05, Lukas Sandström <lukass@etek.chalmers.se> wrote:
> >>>>I think making allocation/deallocation to the central place is a
> >>>>good cleanup, but I am not sure about the free-nodes reusing.
> >>>>Does this make difference in real life?
> >>>
> >>>It definitely does, though nor very much. I have no real numbers at
> >>>hand (being home now), but I remember it was 1 min with against 3 min
> >>>without the patch on cygwin+fat32, which is already bad enough all by
> >>>itself. Very big repository with no redundant packs in it.
> >>
> >>Would you mind sharing the .idx files?
> >
> > this time I probably would (they're not here)... But for a perfomance
> > testing any big repository will do, linux kernel, for example.
> >
> The problem is that the large repository I have contains lots of
> redundant packs, which makes quite fast to find a complete set
> and end the search. If you don't have any redundant packs, the
> complete set search really is 2**n (n = the number of packs).
>
> I did some quick experiments with slab allocation and got a 4.4%
> improvement on the redundant repo, so that might be worth persuing.
> (Concept patch below)
>

I don't have the old packs anymore, but I benchmarked all three
allocation types anyway:

malloc/free:

$ time git-pack-redundant --all --alt-odb
real    0m0.092s
user    0m0.108s
sys     0m0.015s

simple node reuse (the patch in official tree):

$ time git-pack-redundant --all --alt-odb
real    0m0.074s
user    0m0.093s
sys     0m0.015s

slab node allocation (your concept patch):

$ time git-pack-redundant --all --alt-odb
real    0m0.031s
user    0m0.046s
sys     0m0.015s

This repository has one pack and 17758 files.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html