Re: [GSoC] Designing a faster index format - Progress report week 13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
>
>> Junio's index-v4 was a speed boost mainly because it cuts down on the
>> size of the index.  Do we want to throw that out?
>
> That's pretty much orthogonal, isn't it?
>
> The index-v4 is merely to show how a stupid prefix compression of
> pathnames without nothing else would reduce the file size and I/O
> cost, in order to set the bar for anything more clever than that.
>
> I thought that this discussion is about keeping, squishing, or
> discarding part of the cached stat info, and nobody is suggesting
> what to do with the prefix compression of pathnames.

True, sorry for being so confusing.  'Throw "that" out' was meant to
refer to the observation that smaller indexes are generally faster.

Whether this matters in the long run is another question.  Perhaps
partial loading combined with something like inotify can avoid full
reads in most operations.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]