[squeak-dev] Serious garbage/storage leak issue with MCInfoProxy

Bob Arning arning315 at comcast.net
Tue Feb 20 09:56:59 UTC 2018


Probably good enough might be

World allMorphsDo: [:ea | ea removeProperty: #dropShadow]

takes 0 ms for me


On 2/20/18 2:46 AM, Marcel Taeumel wrote:
> Hi Eliot,
>
> sure. Removing the potential drop shadow of all kinds of morphs takes 
> time:
>
> Morph allSubInstancesDo: [:ea | ea removeProperty: #dropShadow].
>
> About 3 seconds here in a quite clean image.
>
> SystemWindow allSubInstancesDo: [:ea | ea removeProperty: #dropShadow].
>
> Works at 100 milliseconds.
>
> What has the biggest effect in your image?
>
> Best,
> Marcel
>>
>> Am 20.02.2018 02:51:06 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>>
>> Hi Marcel,
>>
>>     I've finally worked out that the space overhead here comes from 
>> the dropShadow cache system in Morphs (in otherProperties in 
>> MorphExtensions).  Would it be possible to arrange to flush all drop 
>> shadows in the current project when:
>> - exiting a project
>> - snapshotting
>> ?
>>
>> On Thu, Jan 18, 2018 at 3:24 PM, Eliot Miranda 
>> <eliot.miranda at gmail.com <mailto:eliot.miranda at gmail.com>> wrote:
>>
>>     Hi All,
>>
>>         I've been experiencing image save slowdowns recently and
>>     finally my work image reached 1.%Gb and I thought I better take a
>>     look:
>>
>>     Sisyphus.Cog$ ls -lh SpurWork64.* save/SpurWork64-*
>>     -rw-r--r--@ 1 eliot  staff    28M Jan 18 12:47 SpurWork64.changes
>>     -rw-r--r--@ 1 eliot  staff   1.6G Jan 18 12:48 SpurWork64.image
>>     -rw-r--r--@ 1 eliot  staff    28M Jan 18 12:03
>>     save/SpurWork64-2018-01-18.changes
>>     -rw-r--r--@ 1 eliot  staff   1.5G Jan 18 12:03
>>     save/SpurWork64-2018-01-18.image
>>
>>     I ran a space analysis and found that Bitmap and ByteArray were
>>     the top two, so I looked for large Bitmaps.  I found three that
>>     fit this criterion:
>>
>>
>>         Bitmap allInstances select: [:bm| bm size >= 1000000 and: [bm
>>     ~~ Display bits]]
>>
>>     I inspected the three and did a chase pointers on one of them. 
>>     As I did that suddenly
>>     a) the inspector on the Array became empty (still an array but
>>     zero elements)
>>     b) the progress bar for Downloading FlexibleVocabularies-who.NN
>>     appeared
>>
>>     I interrupted this and did a very cursory stack examination. Some
>>     object had not understood isLiteral and from there what looked
>>     like an attempt to turn this stub into a real object caused
>>     FlexibleVocabularies-who.NN to start to download.
>>
>>     I threw away the debugger, ran the GC and suddenly all my free
>>     space was back.  So now on disc I have
>>
>>     Sisyphus.Cog$ ls -lh SpurWork64.* save/SpurWork64-*
>>     -rw-r--r--@ 1 eliot  staff    28M Jan 18 15:17 SpurWork64.changes
>>     -rw-r--r--@ 1 eliot  staff    57M Jan 18 15:17 SpurWork64.image
>>     -rw-r--r--@ 1 eliot  staff    28M Jan 18 12:03
>>     save/SpurWork64-2018-01-18.changes
>>     -rw-r--r--@ 1 eliot  staff   1.5G Jan 18 12:03
>>     save/SpurWork64-2018-01-18.image
>>
>>     What is going on here?  There seems to be a very bad storage
>>     leak.  Can we please discuss this?  This doesn't seem like
>>     healthy behaviour at all :-)
>>
>>     _,,,^..^,,,_
>>     best, Eliot
>>
>>
>>
>>
>> -- 
>> _,,,^..^,,,_
>> best, Eliot
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180220/b18a3b01/attachment.html>


More information about the Squeak-dev mailing list