[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
|