I had a different idea to solve this issue:

Unroll the ancestry tree to a list. Create a modified MCScanner, which can 
read a list of versions. A list item would look like the current tree 
nodes, but the ancestry and stepChildren lists were just references to the 
actual ancestors/stepChildren in the list.
This would enable partial parsing of the ancestry info. A reference could
contain the position of the referenced list item in the version list, so 
we wouldn't have to parse the intermediate elements.

For backwards compatibility this new version list would be stored in a 
separate file in the .mcz files. This way old versions of MC could still 
load the package, but newer versions with the new scanner could read them 
much faster.


Levente

On Wed, 14 Aug 2013, Chris Muller wrote:

> A little ditty to move toward sustainable ancestry.  After selecting
> "flush cached versions" from the menu, the ancestry-tree will now be
> like this:
>
> aMCVersionInfo.27
>     'ancestry' = anArray
>          1 = aMCVersionInfo.26
>               'ancestry' = anArray
>                    1 = aMCVersionInfo.25
>                         'ancestry' = anArray
>                              1 = aMCInfoProxy(trimmed  'info',
> 'repository' to re-retrieve it)
>
> Truncating the ancestry hierarchies this way recovers about 2.5MB of image size.
>
> Special notes:
>
> - It keeps the most-recent 10 and snips off the ancestry starting
> 10-versions ago to replace it with a MCInfoProxy.  Most any operation
> that uses ancestry will cause the original full MCVersionInfo tree to
> need to be re-retrieved.
>
> - This assumes the Info of 10 versions ago exists in the same
> repository as the current version.  In practice, it normally will.
>
> - When a new version is saved after recovering the Info tree from
> ANOTHER FILE. (e.g., the one 10 versions ago) the result is an
> ancestry tree built from multiple files.  But it's the same tree, so
> this should be no problem.
>
>