<body><div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
+1 :-)<div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 19.01.2018 12:51:26 schrieb Bert Freudenberg <bert@freudenbergs.de>:</p>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div class="gmail_default" style="font-family: arial,helvetica,sans-serif;font-size: 10pt;color: #000000"><span style="font-family:arial,sans-serif;color:rgb(34,34,34)">On 19 January 2018 at 05:30, Chris Muller </span><span dir="ltr" style="font-family:arial,sans-serif;color:rgb(34,34,34)"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span><span style="font-family:arial,sans-serif;color:rgb(34,34,34)"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It wasn't clear to me that your bloated image issue was related to<br>
MCInfoProxy at all -- you said it showed ByteArray's and Bitmaps as<br>
the top, but the Proxy wasn't agitated until you ran the<br>
pointer-finder.<br>
<br>
As I mentioned, the intention of the design is to allow purging the MC<br>
ancestry to recover that memory for building a smaller, tighter<br>
production image, without losing the ability to access it,<br>
transparently, if needed. Because no one would want to accidentally<br>
save a version with the ancestry gone (corrupt), right? This design requires<br>
no extra thinking, just a little extra waiting. Conceptually, that<br>
feels like a classic cache, to me. If there's a glitch in how it<br>
interacts with MC that could be improved, we should fix it. I'm<br>
curious what else was on that stack..<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family: arial,helvetica,sans-serif;font-size: 10pt;color: rgb(0,0,0)">I've voiced my criticism of that design before, so I'll just point out that it's exactly this unpredictable nature of proxy interactions that makes it fragile.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree, though, it isn't needed on the UI menu, so we should remove<br>
it. It's something one would normally only call from a<br>
deployment/build script.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family: arial,helvetica,sans-serif;font-size: 10pt;color: rgb(0,0,0)">+1</div><div class="gmail_default" style="font-family: arial,helvetica,sans-serif;font-size: 10pt;color: rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family: arial,helvetica,sans-serif;font-size: 10pt;color: rgb(0,0,0)">If even Master Eliot is confused, we really should not expose it with one tempting click ;)</div><div class="gmail_default" style="font-family: arial,helvetica,sans-serif;font-size: 10pt;color: rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family: arial,helvetica,sans-serif;font-size: 10pt;color: rgb(0,0,0)">- Bert -</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
Chris<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Jan 18, 2018 at 9:43 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
> Hi Chris,<br>
><br>
> On Thu, Jan 18, 2018 at 7:20 PM, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
>><br>
>> Hi Eliot,<br>
>><br>
>> It sounds like you selected 'flush cached versions and ancestry' from<br>
>> the Repository menu of the Monticello Working Copy browser.<br>
>><br>
>> That's something that you would only want to do for a production<br>
>> deployment image where you aren't planning to do any more development<br>
>> in. It saves memory on ancestry while providing a dynamic (albeit,<br>
>> slow) means of loading it back on the rare case that one would need to<br>
>> do that in the production image ever again. The PointerFinder is not<br>
>> sensitive enough for proxies, so using it ends up agitating them into<br>
>> reification, forcing the dynamic reload of ancestry like you<br>
>> experienced.<br>
>><br>
>> What you want is simply, "flush cached versions" and then you'll never<br>
>> have that issue.<br>
><br>
><br>
> Can you explain? How does this create the issue? Why have an item like<br>
> "flush cached versions and ancestry" if its dangerous. The implication of<br>
> :cached" is that the information can be rebuilt when required. The ancestry<br>
> is out there in the .mcz files. I don't understand what's going on here.<br>
> feels like a bad design decision.<br>
><br>
>><br>
>><br>
>> - Chris<br>
>><br>
>> On Thu, Jan 18, 2018 at 5:24 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>><br>
>> wrote:<br>
>> > Hi All,<br>
>> ><br>
>> > I've been experiencing image save slowdowns recently and finally my<br>
>> > work<br>
>> > image reached 1.%Gb and I thought I better take a look:<br>
>> ><br>
>> > Sisyphus.Cog$ ls -lh SpurWork64.* save/SpurWork64-*<br>
>> > -rw-r--r--@ 1 eliot staff 28M Jan 18 12:47 SpurWork64.changes<br>
>> > -rw-r--r--@ 1 eliot staff 1.6G Jan 18 12:48 SpurWork64.image<br>
>> > -rw-r--r--@ 1 eliot staff 28M Jan 18 12:03<br>
>> > save/SpurWork64-2018-01-18.<wbr>changes<br>
>> > -rw-r--r--@ 1 eliot staff 1.5G Jan 18 12:03<br>
>> > save/SpurWork64-2018-01-18.<wbr>image<br>
>> ><br>
>> > I ran a space analysis and found that Bitmap and ByteArray were the top<br>
>> > two,<br>
>> > so I looked for large Bitmaps. I found three that fit this criterion:<br>
>> ><br>
>> ><br>
>> > Bitmap allInstances select: [:bm| bm size >= 1000000 and: [bm ~~<br>
>> > Display<br>
>> > bits]]<br>
>> ><br>
>> > I inspected the three and did a chase pointers on one of them. As I did<br>
>> > that suddenly<br>
>> > a) the inspector on the Array became empty (still an array but zero<br>
>> > elements)<br>
>> > b) the progress bar for Downloading FlexibleVocabularies-who.NN appeared<br>
>> ><br>
>> > I interrupted this and did a very cursory stack examination. Some object<br>
>> > had<br>
>> > not understood isLiteral and from there what looked like an attempt to<br>
>> > turn<br>
>> > this stub into a real object caused FlexibleVocabularies-who.NN to start<br>
>> > to<br>
>> > download.<br>
>> ><br>
>> > I threw away the debugger, ran the GC and suddenly all my free space was<br>
>> > back. So now on disc I have<br>
>> ><br>
>> > Sisyphus.Cog$ ls -lh SpurWork64.* save/SpurWork64-*<br>
>> > -rw-r--r--@ 1 eliot staff 28M Jan 18 15:17 SpurWork64.changes<br>
>> > -rw-r--r--@ 1 eliot staff 57M Jan 18 15:17 SpurWork64.image<br>
>> > -rw-r--r--@ 1 eliot staff 28M Jan 18 12:03<br>
>> > save/SpurWork64-2018-01-18.<wbr>changes<br>
>> > -rw-r--r--@ 1 eliot staff 1.5G Jan 18 12:03<br>
>> > save/SpurWork64-2018-01-18.<wbr>image<br>
>> ><br>
>> > What is going on here? There seems to be a very bad storage leak. Can<br>
>> > we<br>
>> > please discuss this? This doesn't seem like healthy behaviour at all<br>
>> > :-)<br>
>> ><br>
>> > _,,,^..^,,,_<br>
>> > best, Eliot<br>
>> ><br>
>> ><br>
>> ><br>
>><br>
><br>
><br>
><br>
> --<br>
> _,,,^..^,,,_<br>
> best, Eliot<br>
<br>
</div></div></blockquote></div><br></div></div>
</blockquote>
</div></body>