On Wed, 2016-03-09 at 15:21 -0800, Junio C Hamano 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)? >
1. If the index were stored on a ramdisk, we would *also* have to write it to durable storage to avoid losing the user's work when they power off. That's more complicated. 2. Duy notes that it is easier to add further optimizations to this -- for instance, we could share a pre-parsed version of the index. It would be harder to add these optimizations to the disk format, because (a) they would take up more space, and (b) they would probably be harder to write in a single pass, which is presently how index writing works. 3. If we wanted to just skip SHA-1 verification, we would not need a ramdisk; it's almost certain that the index would be in the disk cache most of the time, so regular storage should be very nearly as fast as a ramdisk. I think mlock might help ensure that the data remains in the cache, although I'm not sure what the permissions story is on that. -- 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
