On Thu, 2016-03-10 at 18:17 +0700, Duy Nguyen wrote: > On Thu, Mar 10, 2016 at 6:21 AM, Junio C Hamano <gits...@pobox.com> > wrote: > > Junio C Hamano <gits...@pobox.com> writes: > > > > > David Turner <dtur...@twopensource.com> writes: > > > > > > > From: Nguyễn Thái Ngọc Duy <pclo...@gmail.com> > > > > > > > > Instead of reading the index from disk and worrying about disk > > > > corruption, the index is cached in memory (memory bit-flips > > > > happen > > > > too, but hopefully less often). The result is faster read. Read > > > > time > > > > is reduced by 70%. > > > > > > > > The biggest gain is not having to verify the trailing SHA-1, > > > > which > > > > takes lots of time especially on large index files. > > > > Come to think of it, wouldn't it be far less intrusive change to > > just put the index on a ramdisk and skip the trailing SHA-1 > > verification, to obtain a similar result with the same trade off > > (i.e. blindly trusting memory instead of being paranoid)? > > I'm straying off-topic again because this reminded me about lmdb :) > For the record when I looked at lmdb I thought of using it as an > index > format too. It has everything we wanted in index-v5. Good enough that > we would not need index-helper and split-index to work around current > index format. Though I finally decided it didn't fit well. > > On the good side, lmdb is b+ trees, we can update directly on disk > (without rewriting whole file), read directly from mmap'd file and > not > worry about corrupting it. There's no SHA-1 verification either (and > we can do crc32 per entry if we want too). It's good. > > But, it does not fit well the our locking model (but we can change > this). And we sometimes want to create temporary throw-away indexes > (e.g. partial commits) which I don't think is easy to do. And the > reading directly from mmap does not give us much because we have to > do > byte endian conversion anyway. > > Hmm.. on second thought, even though lmdb can't be the default format > (for a bunch of other limitations), it can still be an option for > super big worktrees, just like index-helper being an optional > optimization. Hm.. hm.. if we can support lmdb as index format in > addition to the current format, bringing back some work from Thomas.. > We may still need a daemon or something to deal with watchman, but > the > underlying mechanism is exactly the same... David, Junio, what do you > think?
LMDB makes writes faster, since we only have to write the stuff that's changed. That's good. Reads (ignoring SHA verification) will be slightly slower (due to the btree overhead). If, in general, we only had to read part of the index, that would be faster. But a fair amount of git code is written to assume that it is reasonable to iterate over the whole index. So I don't see a win from just switching to LMDB without other changes. (I guess we could parallelize index deserialization more easily with lmdb, but I don't know The original intent of the index was to be a "staging area" to build up a tree before committing it. This implies an alternate view of the index as a diff against some (possibly-empty) tree. An index diff or status operation, then, just requires iterating over the changes. I haven't really dug into merges to understand whether it would be reasonable for them to use a representation like this, and what that would do to speed there. In general, git takes the commit side of the commit-diff duality. This is generally a good thing, because commits are simpler to reason about. But I wonder if we could do better for this specific case. But I don't think switching to LMDB would replace index-helper. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
