Thread (36 messages) flat view 36 messages, 5 authors, 2016-06-16

Re: [PATCH v4 03/16] index-helper: new daemon for caching index and related stuff

From: David Turner <hidden>
Date: 2016-06-16 02:18:49

On Fri, 2016-04-15 at 18:25 +0700, Duy Nguyen wrote:
On Thu, Apr 14, 2016 at 1:47 AM, David Turner <
dturner@twopensource.com> wrote:
quoted
quoted
quoted
+       fd = unix_stream_connect(socket_path);
+       if (refresh_cache) {
+               ret = write_in_full(fd, "refresh", 8) != 8;
Since we've moved to unix socket and had bidirectional
communication,
it's probably a good idea to read an "ok" back, giving index
-helper
time to prepare the cache. As I recall the last discussion with
Johannes, missing a cache here when the index is around 300MB
could
hurt more than wait patiently once and have it ready next time.
It is somewhat slower to wait for the daemon (which requires a disk
load + a memcpy) than it is to just load it ourselves (which is
just a
disk load).
You forgot the most costly part, SHA-1 verification. For very large
index, I assume the index-helper is already in the middle of hashing
the index content. If you ignore index-helper, you need to go hash
the
whole thing again. The index-helper can hand it to you if you wait
just a bit more. This wait time should be shorter because index
-helper
is already in the middle of hashing (and in optimistic case, very
close to finishing it).
You're right -- I did forget that part.

In "index-helper: use watchman to avoid refreshing index with lstat()",
we switch from just poking to poking and waiting for a reply.  Then in
"read-cache: config for waiting for index-helper", we make that waiting
optional.  So what if I just remove that patch?  Does that solve it?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help