Prototype "improved_chk_index"

[Robert Collins]

On Wed, 2009-10-28 at 23:42 -0500, John Arbash Meinel wrote:
> 
> On IRC Robert asked me why I thought this was worthwhile.

I was asking in the light of the format moratorium, not overall - Even
before 2.0 your back of envelope numbers were compelling.

> 3) Still stands. All told,  We have 16MB .cix, 10MB .tix, and 2.3MB
>    .iix and .rix, and 1.4MB .six. For a total of 31MB of indexes. 31MB
>    of index for 100MB of content seems a bit skewed.

Yup.

..
> I don't know about the time to *build* an index, but there could be
> some
> significant gains there as well. (Traditionally compress() is
> significantly slower than decompress(), especially with our current
> sync
> and try again implementation.)

I'm sure we can win there too.

I'd like to inline all the indices into the pack, so we only have one
file to rename and manage. bzr-search does this and it works well.

Related to that I've been considering putting small objects inline in
the index. E.g. putting a revision inline in the revision index; may be
a silly idea, I'm not sure.

One thing to consider with the .tix index is what we want to end up
with. I can see indirecting via .cix for file content, but still we'd
want per file graphs, I think.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20091029/e0729682/attachment.pgp