- Pharo-dev - lists.pharo.org

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

by Marcus Denker

On Aug 1, 2013, at 9:04 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > indeed this is what marcus thought. > So we found a nice bug. > I added a tracker entry: https://pharo.fogbugz.com/f/cases/11291/Announcer-for-Morphs-should-be-Weak (I will be on holidays starting tomorrow afternoon, so no action on this from me for a whileâ¦) Marcus

Aug. 1, 2013

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

by StÃ©phane Ducasse

indeed this is what marcus thought. So we found a nice bug. Stef On Aug 1, 2013, at 7:47 PM, phil(a)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(a)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(a)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(a)highoctane.be <phil(a)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(a)inria.fr> wrote: > > On Aug 1, 2013, at 1:31 AM, phil(a)highoctane.be wrote: > >> Doing the flushCaches... >> >> Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/estebanlm/EclipsePack/m… : 324017564 >> Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/estebanlm/EclipsePack/m… : 324137232 >> Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/DripfeedIt… : 324137232 >> Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/DripfeedIt… : 324195720 >> Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOWebStack… : 324195720 >> Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOWebStack… : 324255300 >> Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOExperime… : 324255300 >> Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOExperime… : 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(a)acm.org > http://www.marcusdenker.de > > > <WindowLabelled-labels.txt.gz>

Aug. 1, 2013

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

by phil＠highoctane.be

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(a)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(a)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(a)highoctane.be <phil(a)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(a)inria.fr>wrote: >>> >>>> >>>> On Aug 1, 2013, at 1:31 AM, phil(a)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(a)acm.org >> http://www.marcusdenker.de >> > >

Aug. 1, 2013

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

by phil＠highoctane.be

I got a pretty large number with these announcements... provided nothing special is running at the moment... Announcement allSubInstances size. 14120 And: (Announcement allSubInstances collect: [ :a | a class ]) asSet a Set(WindowOpened WindowLabelled WindowClosed KMCompleteMatch TestSuiteEnded ClassRemoved) And ann:=(Announcement allSubInstances collect: [ :a | a class ]) asSet. ann do: [ :each | Transcript nextPutAll: each className; nextPut: $:; nextPutAll: each allInstances size printString;cr]. Transcript flush. gives: WindowOpened class:WindowOpened class:953 WindowOpened class:956 WindowLabelled class:11837 WindowClosed class:1345 KMCompleteMatch class:6 TestSuiteEnded class:1 ClassRemoved class:1 Well, 11837 for WindowLabelled is quite large. Hope it gives a hint. Phil

Aug. 1, 2013

Re: [Pharo-dev] killing all uses of caseOf: and caseOf:otherwise from the image

by Frank Shearar

On 1 August 2013 15:20, Igor Stasenko <siguctua(a)gmail.com> wrote: > We had quite hot discussion about this topic in the past.. > I don't think it makes sense to repeat arguments.. > because i think it won't convert anyone in either camp (those who > [dis]agree, will still [dis]agree). > so, lets just move on. In a way I'm not asking about the merits or otherwise of #caseOf:. I'm just wondering about what you _gain_ by removing the calls. Replacing type-switching code with polymorphism is almost always a clear win, for instance. But "kill all (non-type-switching) senders" doesn't give you much, except harder to read chained if/elses. frank > -- > Best regards, > Igor Stasenko. >

Aug. 1, 2013

Re: [Pharo-dev] killing all uses of caseOf: and caseOf:otherwise from the image

by Igor Stasenko

We had quite hot discussion about this topic in the past.. I don't think it makes sense to repeat arguments.. because i think it won't convert anyone in either camp (those who [dis]agree, will still [dis]agree). so, lets just move on. -- Best regards, Igor Stasenko.

Aug. 1, 2013

Re: [Pharo-dev] Windows problem with FilePlugin ?

by Marcus Denker

On Aug 1, 2013, at 4:17 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > Yep :) > > Thanks for your help. > I opened an issue for that (11293) and I will try to tackle it tonight > There is already 11195 FileBrowser Tree in Pharo 3.0 does not work on Windows https://pharo.fogbugz.com/f/cases/11195

Aug. 1, 2013

Re: [Pharo-dev] Windows problem with FilePlugin ?

by Benjamin

Yep :) Thanks for your help. I opened an issue for that (11293) and I will try to tackle it tonight Ben On Aug 1, 2013, at 4:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor did not tell you but I see strange blue window and windows on his machine and red square of deathâ¦. > So he is looking at it. > > Stef > > On Aug 1, 2013, at 1:01 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> On my image, when opened in Windows, opening the File Browser leads to a red square of death :s >> >> And using the UIManager to popup the file picker leads to an infinite loop of halt :s >> >> Do you experienced that too ? >> >> >> Can people using windows try the following line: >> >> (FileSystem disk root) directories >> >> This gives me C:, D:, F:, G: where actually only C: and G: are presentâ¦ >> >> >> It seems to come from >> DiskStore>>#basicEntry:path:nodesDo: >> [â¦] >> >> [ entry isNil ] >> whileFalse: [ >> entry at: 1 put: (Primitives decode: entry first). >> aBlock value: entry. >> index := index + 1. >> entry := Primitives lookupEntryIn: encodedPathString index: index ]. >> >> So I would say it comes from the primitives. >> >> Ben > >

Aug. 1, 2013

Re: [Pharo-dev] Windows problem with FilePlugin ?

by Igor Stasenko

On 1 August 2013 16:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor did not tell you but I see strange blue window and windows on his machine and red square of deathâ¦. > So he is looking at it. > i did in fact.. i was chatting with Ben all the time :) > Stef > > On Aug 1, 2013, at 1:01 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> On my image, when opened in Windows, opening the File Browser leads to a red square of death :s >> >> And using the UIManager to popup the file picker leads to an infinite loop of halt :s >> >> Do you experienced that too ? >> >> >> Can people using windows try the following line: >> >> (FileSystem disk root) directories >> >> This gives me C:, D:, F:, G: where actually only C: and G: are presentâ¦ >> >> >> It seems to come from >> DiskStore>>#basicEntry:path:nodesDo: >> [â¦] >> >> [ entry isNil ] >> whileFalse: [ >> entry at: 1 put: (Primitives decode: entry first). >> aBlock value: entry. >> index := index + 1. >> entry := Primitives lookupEntryIn: encodedPathString index: index ]. >> >> So I would say it comes from the primitives. >> >> Ben > > -- Best regards, Igor Stasenko.

Aug. 1, 2013

Re: [Pharo-dev] Windows problem with FilePlugin ?

by StÃ©phane Ducasse

Igor did not tell you but I see strange blue window and windows on his machine and red square of deathâ¦. So he is looking at it. Stef On Aug 1, 2013, at 1:01 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > On my image, when opened in Windows, opening the File Browser leads to a red square of death :s > > And using the UIManager to popup the file picker leads to an infinite loop of halt :s > > Do you experienced that too ? > > > Can people using windows try the following line: > > (FileSystem disk root) directories > > This gives me C:, D:, F:, G: where actually only C: and G: are presentâ¦ > > > It seems to come from > DiskStore>>#basicEntry:path:nodesDo: > [â¦] > > [ entry isNil ] > whileFalse: [ > entry at: 1 put: (Primitives decode: entry first). > aBlock value: entry. > index := index + 1. > entry := Primitives lookupEntryIn: encodedPathString index: index ]. > > So I would say it comes from the primitives. > > Ben

Aug. 1, 2013