Thread (11 messages) flat view 11 messages, 4 authors, 2016-06-15

Re: [RFC] On watchman support

From: David Turner <hidden>
Date: 2016-06-15 23:02:58

On Tue, 2014-11-18 at 17:48 +0700, Duy Nguyen wrote:
quoted
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?
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.  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help