On Sun, Sep 25, 2011 at 10:43 PM, Martin Fick <mfick@xxxxxxxxxxxxxx> wrote:
> A coworker of mine pointed out to me that a simple
>
> git checkout
>
> can also take rather long periods of time > 3 mins when run
> on a repo with ~100K refs.
Are all these refs packed?
> While this is not massive like the other problem I reported,
> it still seems like it is more than one would expect. So, I
> tried an older version of git, and to my surprise/delight,
> it was much faster (.2s). So, I bisected this issue also,
> and it seems that the "offending" commit is
> 680955702990c1d4bfb3c6feed6ae9c6cb5c3c07:
>
> commit 680955702990c1d4bfb3c6feed6ae9c6cb5c3c07
> Author: Christian Couder <chriscool@xxxxxxxxxxxxx>
> Date: Fri Jan 23 10:06:53 2009 +0100
>
> replace_object: add mechanism to replace objects found
> in "refs/replace/"
[...]
> Now, I suspect this commit is desirable, but I was hoping
> that perhaps a look at it might inspire someone to find an
> obvious problem with it.
I don't think there is an obvious problem with it, but it would be
nice if you could dig a bit deeper.
The first thing that could take a lot of time is the call to
for_each_replace_ref() in this function:
+static void prepare_replace_object(void)
+{
+ static int replace_object_prepared;
+
+ if (replace_object_prepared)
+ return;
+
+ for_each_replace_ref(register_replace_ref, NULL);
+ replace_object_prepared = 1;
+}
Another thing is calling replace_object_pos() repeatedly in
lookup_replace_object().
Thanks,
Christian.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html