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!