Re: git-index-pack really does suck..
On Tue, 3 Apr 2007, Linus Torvalds wrote:
>
> Junio, Nico,
> I think we need to do something about it.
Show 9 quoted lines
> CLee was complaining about git-index-pack on #irc with the partial KDE
> repo, and while I don't have the KDE repo, I decided to investigate a bit.
>
> Even with just the kernel repo (with a single 170MB pack-file), I can do
>
> git index-pack --stdin --fix-thin new.pack < .git/objects/pack/pack-*.pack
>
> and it uses 52s of CPU-time, and on my 4GB machine it actually started
> doing IO and swapping, because git-index-pack grew to 4.8GB in size.
Show 22 quoted lines
> Two suggestion for other ways:
>
> - simple one: don't keep unexploded objects around, just keep the deltas,
> and spend tons of CPU-time just re-expanding them if required.
>
> We *should* be able to do it with just keeping the original 170MB
> pack-file in memory, not expanding it to 3.8GB!
>
> Still, even this will be painful once you have a big pack-file, and the
> CPU waste is nasty (although a delta-base cache like we do in
> sha1_file.c would probably fix it 99% - at that point it's getting
> less simple, and the "best" solution below looks more palatable)
>
> - best one: when writing out the pack-file, we incrementally keep a
> "struct packed_git" around, and update the index for it dynamically,
> and totally get rid of all objects that we've written out, because we
> can re-create them.
>
> This means that we should have _zero_ memory footprint except for the
> one object that we're working on right then and there, and any
> unresolved deltas where we've not seen the base at all (and the latter
> generally shouldn't happen any more with most pack-files)
Even better:
- Fix my own stupid mistake with a _single_ line of code:
diff --git a/index-pack.c b/index-pack.c
index 6284fe3..3c768fb 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -358,6 +358,7 @@ static void sha1_object(const void *data, unsigned long size,
if (size != has_size || type != has_type ||
memcmp(data, has_data, size) != 0)
die("SHA1 COLLISION FOUND WITH %s !", sha1_to_hex(sha1));
+ free(has_data);
}
}
The thing is, that code path is executed _only_ when index-pack is
encountering an object already in the repository in order to protect
against possible SHA1 collision attacks. See commit 8685da42561d log
for the full story.
Normally this should not happen in normal usage scenarios because the
objects you fetch are those that you don't already have. But if you
manually run index-pack inside an existing repository then you'll
already have _all_ those objects already explaining the high CPU usage.
But this is no excuse for not freeing the data though.
Nicolas
Nicolas Pitre <nico@cam.org>