On Fri, 14 Nov 2014, Bert Freudenberg wrote:

> On 14.11.2014, at 16:17, Chris Muller <asqueaker at gmail.com> wrote:
>
>> On Thu, Nov 13, 2014 at 8:15 PM, tim Rowledge <tim at rowledge.org> wrote:
>>> Even after use of doits such as         MCFileBasedRepository flushAllCaches & MCDefinition clearInstances I have 9500 MCVersionInfo and similar numbers of other MC related objects in my image. And 990 SMAccounts? 800 SMPackage? 13000 UUIDs? That all seems a bit excessive somehow.
>>>
>>> I know there was a conversation about chopping at least some of the MC stuff out (which I think is where the flushAllCaches came from) but it seems there is an awful lot left that could be removed as part of making a deployment image.
>>
>> There is also 'flush cached versions and ancestry' on the MC
>> repository menu next to 'flush all caches', which goes back just 10
>> versions ago and trims the MCInfoProxy tree from there.  Space
>> consumed by 95% of your MCInfoProxy instances is recovered, without
>> actually losing any data.  The proxy will reload them dynamically if
>> asked (e.g., by you clicking on History button of a package).
>>
>> I know Bert doesn't like it, but Smalltalk is an environment that's
>> supposed to support "debugging in production".  There is a common
>> usage case in MC that causes the Proxy's to be prematurely agitated
>> unnecessarily, resulting in a delay while they're re-loaded, which
>> nobody liked (understandably).  I never had time to investigate that
>> but if you do, that'd be really great.
>>
>> The thing I don't care for about Berts solution is the hindrance to
>> debugging in production.  Invariably it will happen by necessity.
>> After making a code-fix, someone might be tempted to re-add the
>> WorkingCopy and then save the package -- losing all the ancestry!
>
> Stripping and deployment was never discussed when you introduced this, and enabled it, by default, for all developers. That was one reason I was opposed.
>
> For a deployed image the stubbed ancestry might be much better indeed - and for that use case I wouldn't even retain 10 levels of history, but strip it down to a single version info per package. Just the bare info needed to pull in the full ancestry. (I also would make re-instating the full version hierarchy an explicit action rather than a side effect, but we had that discussion already).

All we need is a new format for the VersionInfos, which can be read 
sequentially (one by one). Instead of storing one huge smalltalk array, 
we could store one array per version. Ancestors and stepChildren could 
reference the versions by name and uuid, or maybe by an offset. I think 
that would be so fast that we wouldn't want to keep the ancestry in memory 
anymore.
All we would lose is the possiblity to create a snapshot without having 
the ancestors around in a repository.
Another thing is that the snapshots would have to contain both the new and 
the old format for compatibility with other smalltalks and older images.

Levente

>
> - Bert -
>
>