Re: [RFC] On watchman support

From: David Turner <dturner@twopensource.com>
Date: Nov 18, 2014, 18:12 UTC
Message-ID: <1416334360.27401.10.camel@leckie>
In-Reply-To: <CACsJy8BfxP7KF1XF29BOgC6XhO8iAy-ycEoLkDG5rn6TYH_DrA@mail.gmail.com>

On Tue, 2014-11-18 at 17:48 +0700, Duy Nguyen wrote:

Show 9 quoted lines

> > My patches are not the world's most beautiful, but they do work.  I
> > think some improvement might be possible by keeping info about tracked
> > files in the index, and only storing the tree of ignored and untracked
> > files separately.  But I have not thought this through fully.  In any
> > case, making use of shared memory for the fs_cache (as some of your
> > other patches do for the index) would definitely save time.
> 
> By the way, what happened to your sse optimization in refs.c? I see
> it's reverted but I didn't follow closely to know why.

I don't know why either -- it works just fine. There was a bug, but I fixed it. Junio?

Show 5 quoted lines

> Or will you go
> with cityhash now.. I ask because you have another sse optimization
> for hashmap on your watchman branch and that could reduce init time
> for name-hash. Name-hash is used often on case-insensitive fs (less
> often on case-sensitive fs).

Cityhash would be better, because it has actual engineering effort put into it; what I did on my branch is a hack that happens to work decently. As the comment notes, I did not spend much effort on tuning my implementation. Also, Cityhash doesn't require SSE, so it's more portable.

> I did a simple test and your optimization could init name-hash (on
> webkit) in 35ms, while unmodified hashmap took 88ms. Loading index on
> this machine took 360ms for reference (probably down too 100ms with
> index-helper running, when that 88ms starts to become significant).

OK, that sounds like a big win.