[Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

Stéphane Ducasse stephane.ducasse at inria.fr
Thu Aug 1 15:03:56 EDT 2013


indeed this is what marcus thought.
So we found a nice bug.

Stef

On Aug 1, 2013, at 7:47 PM, phil at highoctane.be wrote:

> Continuing on the topic, it looks like that every single window that I ever opened is remembered by the Announcements...
> 
> Cursor wait showWhile: [ 
> 	(FileSystem disk workingDirectory / 'WindowLabelled-labels.txt') asFileReference writeStreamDo: [  :s |
> 
> 		WindowLabelled allInstances do: [  :each | each label printOn: s. s lf ].
> 
> 	]
> ].
> 
> The attached file is what I got. 
> 
> Phil
> 
> On Thu, Aug 1, 2013 at 3:47 PM, Guillermo Polito <guillermopolito at gmail.com> wrote:
> Ok, we are looking at that with marcus.
> 
> So, one thing that may be causing problems is that there are some usages of #onAnnouncement: anAnnouncement do: aBlock. And since we don't have ephermerons, the usage of blocks in announcements is leaking references.
> 
> Also, looking at the usages of onAnnouncement:do:, we found NECController>>setEditor:, which is called for every keystroke in when using autocompletion :D. Maybe the cause is around here?
> 
> 
> 
> 
> On Thu, Aug 1, 2013 at 1:40 PM, Marcus Denker <marcus.denker at inria.fr> wrote:
> Yes, I think the announcers of morph might be the cause of the problem...
> 
> 
> On Thu, Aug 1, 2013 at 1:09 PM, phil at highoctane.be <phil at highoctane.be> wrote:
> I did a little run on those MorphExtensions and got the output file in annex.
> 
> Cursor wait showWhile: [ 
> (FileSystem disk workingDirectory / 'MorphExtensions.txt') asFileReference writeStreamDo: [  :s |
> 	MorphExtension allInstancesDo: [ :each |
> 		each printOn: s.
> 	      s lf 
> 	]
> ]
> ].
> 
> Looks like there are a lot of Announcers.
> 
> Phil
> 
> 
> On Thu, Aug 1, 2013 at 9:35 AM, Marcus Denker <marcus.denker at inria.fr> wrote:
> 
> On Aug 1, 2013, at 1:31 AM, phil at highoctane.be wrote:
> 
>> Doing the flushCaches...
>> 
>> Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324017564
>> Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324137232
>> Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324137232
>> Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324195720
>> Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324195720
>> Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324255300
>> Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : 324255300
>> Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : 324314868
>> 
>> Definitely not going down...
>> 
> 
> No, we already saw that in your case the reason are many,many instances of MorphExtension without the Morphs hanging around.
> (which should not happen as MorphExtensions are only referenced by the Morph they extend).
> 
> Your case is not a case of caches, there is a real problem somewhere.
> 
> 	Marcus
> 
> 
> 
> 
> 
> -- 
> --
> Marcus Denker  --  denker at acm.org
> http://www.marcusdenker.de
> 
> 
> <WindowLabelled-labels.txt.gz>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20130801/a62a5e56/attachment-0002.html>


More information about the Pharo-dev mailing list