On Fri, Mar 29, 2013 at 04:32:00PM -0400, Jeff King wrote:
> > Agreed. Although I think it's getting out of my domain. I'm not even
> > sure how many factors are involved.
>
> There's the load factor that causes us to grow, and the growth factor of
> how aggressively we expand when we do need to
On Fri, Mar 29, 2013 at 10:29:52PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Fri, Mar 29, 2013 at 10:12 PM, Jeff King wrote:
> > This feels weirdly specific, and like we should just be tuning our hash
> > table growth better. You show a 3.2% speedup here. I was able to get a
> > 2.8% speedup just b
Jeff King writes:
> This feels weirdly specific, and like we should just be tuning our hash
> table growth better. You show a 3.2% speedup here. I was able to get a
> 2.8% speedup just by doing this:
>
> diff --git a/object.c b/object.c
> index 20703f5..8e5e12c 100644
> --- a/object.c
> +++ b/obj
On Fri, Mar 29, 2013 at 10:12 PM, Jeff King wrote:
> This feels weirdly specific, and like we should just be tuning our hash
> table growth better. You show a 3.2% speedup here. I was able to get a
> 2.8% speedup just by doing this:
It also uses a lot more memory. 5.8m entries for ".. * 2" and 8.
On Fri, Mar 29, 2013 at 08:20:10PM +0700, Nguyen Thai Ngoc Duy wrote:
> Every time the object hash table grows, all entries must be
> rearranged. The few last times could be really expensive when the
> table contains a lot of entries.
>
> When we do "--all --objects" we know in advance we may nee
Every time the object hash table grows, all entries must be
rearranged. The few last times could be really expensive when the
table contains a lot of entries.
When we do "--all --objects" we know in advance we may need to hash
all objects. Just prepare the hash table big enough, so there won't be
6 matches
Mail list logo
