Re: [PATCH 3/5] name-hash: precompute hash values during preload-index

Jeff Hostetler writes: > I looked at doing this, but I didn't think the complexity and overhead to > forward search for peers at the current level didn't warrant the limited > gains. It seems that I wasn't clear what I meant. I didn't mean anything complex like

RE: [PATCH 3/5] name-hash: precompute hash values during preload-index

From: Junio C Hamano [mailto:jch2...@gmail.com] On Behalf Of Junio C Hamano > > The fact that each preload_thread() still walks the index in-order > makes me wonder if it may allow us to further optimize the "dir" > part of the hash by passing the previous ce for which we already > precomputed

Re: [PATCH 3/5] name-hash: precompute hash values during preload-index

Johannes Schindelin writes: > +void precompute_istate_hashes(struct cache_entry *ce) > +{ > + int namelen = ce_namelen(ce); > + > + while (namelen > 0 && !is_dir_sep(ce->name[namelen - 1])) > + namelen--; > + > + if (namelen <= 0) { > +

[PATCH 3/5] name-hash: precompute hash values during preload-index

From: Jeff Hostetler Precompute the istate.name_hash and istate.dir_hash values for each cache-entry during the preload-index phase. Move the expensive memihash() calculations from lazy_init_name_hash() to the multi-threaded preload-index phase. Signed-off-by: Jeff