[squeak-dev] [ANN] MCInfoProxy

Chris Muller ma.chris.m at gmail.com
Thu Aug 15 01:28:21 UTC 2013


When you say it would "enable partial parsing of the ancestry info" I
didn't quite understand how you achieve that.  That's what the new Scanner
does?

If you want to put it to Inbox I'm sure it'll make more sense and we can
evaluate both approaches.

I like what you seem to be saying about trying to trim it on _load_ so we
can always just have a "right-sized" image.  It might be a pipe-dream for
either implementation though, which is why, for now, to have it as part of
the flush-all-caches operation.  So the sizes are, "large and fast" or "as
small as possible," which fit two use-cases, development and deployment,
respectively.

The only way to have something in-between those two is to flush-caches in
your dev image and keep developing.  After a big release of all of them,
only the projects that are worked on enough to invoke their history will be
put back in the image.  So that's one way to "right-size" between the big
and small.

Let me tell you the last step I'd planned for my Proxy implementation.  The
only ancestry access in MCAncestry is pretty much allAncestorsDo: type
stuff that ends up traversing the whole tree.  We could instead have a
Preference of some kind (pragma-based, of course), which defines the size
of what should be considered "recentHistory".  Like, something between 10
and 100.

MCWorkingCopy>>#stubAncestry would be updated to stub everything older than
the preference setting.

Finally, all the operations which today are using allAncestorsDo: would
change to use "recentAncestorsDo:" so that the Proxy would never be hit.
 The preference could be adjusted to balance between development and
deployment interests.

Whether this more complex "sizing" capability would stop me from just doing
a flush-all-caches before deployment.. or care during development..
probably not.  So that's is why I wonder whether attempting this is
useful...


On Wed, Aug 14, 2013 at 3:33 PM, Levente Uzonyi <leves at elte.hu> wrote:

> 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.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130814/36376d56/attachment.htm


More information about the Squeak-dev mailing list