[squeak-dev] Too much MC stuff left in image
bert at freudenbergs.de
Fri Nov 14 16:38:40 UTC 2014
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).
- Bert -
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141114/6b7e7813/smime.bin
More information about the Squeak-dev