June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Johan Brichau

On 26 Jun 2014, at 15:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower. As I said, I understand it would be slower. But an image that runs at 100% for a couple of hours and then just dies because it runs out of memory is not my idea of expected behavior. Mind that the memory only gets freed when I close the browser. If I do a marginally smaller load, the load completes but my image size is stuck at 450 MB until I close the open browser. Johan

June 26, 2014

Re: [Pharo-dev] about ~=

by Esteban A. Maringolo

2014-06-26 8:27 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > -1 for replacing ~= with != because it is not better at all > +1 for avoiding it altogether like you suggest > -1 for changing ~= to mean #closeTo: I like the longer name I adhere to keep the status quo. If one thing confuses people in that realm is non arithmetic precedence: Eg. 2 + 3 * 4 = 20 instead of the "expected" 14. And we're not going to change that either. It's not worthy, and I doubt if it is possible at all. You can always do (aBoolean = otherBoolean) not :) Regards! Esteban A. Maringolo

June 26, 2014

Re: [Pharo-dev] evicted zombie process from run queue

by Esteban A. Maringolo

2014-06-26 10:09 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > you are basically creating 1000 * 100000 morphs (and complex ones). > I would just do a matrix morph with just one morph and rendering the matrix > in the canvas (overriding the #drawOn:) > > BTW, I do not think VW would work like that either: IMO, that design > (pre-generating the cells) is bad and it never works. > Other frameworks use a datasource design (like cocoa, swtâ¦ and basically all > the serious frameworks I know about). > and no, we do not have a default design for this kind of big components (a > serious absence, IMO). A recycling list/container morph would be great, and super fast. I know... lack of manpower... :) Regards!

June 26, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Goubier Thierry

Le 26/06/2014 15:25, Sven Van Caekenberghe a Ã©crit : > > On 26 Jun 2014, at 15:17, Johan Brichau <johan(a)inceptive.be> wrote: > >> I will do that, but the main problem is not the loading speed. >> The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory. >> >> But yes, I will make a ticket and get some more profiling with that so we can fix it. >> Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-) > > I disagree a bit ;-) > > Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up. This means something can be optimized in the browser... Browsers have a very limited view on the underlying code, more or less a subset of a class methods and their relation in higher stuff, such as the package, which means loading a large body of code has little effect on the Browser (unless it's a live CodeCity instance :)). > Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower. Not by much. > Like StÃ©phane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines. I disagree with you there. Disabling updates causes problems in many different places (RPackage, for one) and correct implementation of the Browser updates should not slow it down significantly. And it allow us, in the future, to have a responsive GUI while loading code. I know because after optimising it, it went from very visible to being almost invisible on the profile (far below the time spent #pragma updating). Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 26, 2014

Re: [Pharo-dev] evicted zombie process from run queue

by Stephan Eggermont

Esteban wrote: >Other frameworks use a datasource design (like cocoa, swtâ¦ and basically all the serious frameworks I know about). >and no, we do not have a default design for this kind of big components (a serious absence, IMO). Serious absence indeed. Stephan

June 26, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Goubier Thierry

Le 26/06/2014 15:17, Johan Brichau a Ã©crit : > I will do that, but the main problem is not the loading speed. > The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory. Try with a simple configuration: the announcements should already be visible on the profile. > But yes, I will make a ticket and get some more profiling with that so we can fix it. > Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-) Or switch to another browser :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 26, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Marcus Denker

On 26 Jun 2014, at 15:19, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Thanks for taking care, these things are aways more work than expected. > Indeedâ¦ and the code afterwards always looks so little and so simple ;-) Marcus > On 26 Jun 2014, at 15:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 25 Jun 2014, at 17:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> - Opal needs to delegate code generation to the Slot. >>>> >>> This is now done. Opal now, in the semantic analysis phase, annotates slot accesses >>> as OCSlotVariable (OCInstanceVariable we can remove later). >>> >>> Then when generating, it just forwards to the slot: >>> >>> emitStore: methodBuilder >>> >>> slot emitStore: methodBuilder >>> >> >> This is now finally in the image 4.0 046 >> >> Marcus >> >> > >

June 26, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Sven Van Caekenberghe

On 26 Jun 2014, at 15:17, Johan Brichau <johan(a)inceptive.be> wrote: > I will do that, but the main problem is not the loading speed. > The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory. > > But yes, I will make a ticket and get some more profiling with that so we can fix it. > Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-) I disagree a bit ;-) Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up. Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower. Like StÃ©phane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines. > cheers > Johan > > On 26 Jun 2014, at 09:47, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Sorry to ask then, but: >> >> would it be possible to profile a configurationOf... load with and without a Nautilus open? Time spent handling announcements should be visible, and, yes, when loading code, Browsers have to be aware the code is being changed. >> >> I spent some time optimizing that for AltBrowser, and it can very significantly increase the loading time, without counting in side effects such as over-caching (and I know Nautilus does some caching, but I'm not sure I understand why). >> >> Thierry >> >> Le 25/06/2014 20:20, phil(a)highoctane.be a Ã©crit : >>> Maybe due to some Annoucement being picked up by Nautilus? >>> >>> Phil >>> >>> >>> >>> On Wed, Jun 25, 2014 at 7:57 PM, Johan Brichau <johan(a)inceptive.be >>> <mailto:johan@inceptive.be>> wrote: >>> >>> Hi, >>> >>> It seems that when even a single Nautilus system browser is open and >>> you do a load (using Metacello), there is a huge amount of objects >>> that get created and persisted in the image. >>> This even leads to the point that the image crashes when I try to >>> load our code using a ConfigurationOf. After some time, the Pharo >>> process is stuck at 100%, image size is over 500MB and the entire >>> image becomes unresponsive, finally crashing after an hour or so. >>> >>> I have not yet found which objects or why, but I just wrestled with >>> this all day to find out what was going on. I first thought that >>> Metacello was in an infinite loop but after noticing that the image >>> was so large (500MB) and that it got reduced to 20% of its size >>> after closing the browser window, I can say that Nautilus is >>> gathering garbage. It is definitely not Metacello because I can >>> trigger the same problem doing a load via Monticello only. >>> >>> When I load the ConfigurationOf without a single browser open, it >>> loads 5x faster and the image size stays reasonable. >>> >>> Is this a known issue? Any thoughts on what may be causing this? >>> >>> regards! >>> Johan >>> >>> >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

June 26, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Sven Van Caekenberghe

Thanks for taking care, these things are aways more work than expected. On 26 Jun 2014, at 15:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 25 Jun 2014, at 17:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> - Opal needs to delegate code generation to the Slot. >>> >> This is now done. Opal now, in the semantic analysis phase, annotates slot accesses >> as OCSlotVariable (OCInstanceVariable we can remove later). >> >> Then when generating, it just forwards to the slot: >> >> emitStore: methodBuilder >> >> slot emitStore: methodBuilder >> > > This is now finally in the image 4.0 046 > > Marcus > >

June 26, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Johan Brichau

I will do that, but the main problem is not the loading speed. The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory. But yes, I will make a ticket and get some more profiling with that so we can fix it. Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-) cheers Johan On 26 Jun 2014, at 09:47, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Sorry to ask then, but: > > would it be possible to profile a configurationOf... load with and without a Nautilus open? Time spent handling announcements should be visible, and, yes, when loading code, Browsers have to be aware the code is being changed. > > I spent some time optimizing that for AltBrowser, and it can very significantly increase the loading time, without counting in side effects such as over-caching (and I know Nautilus does some caching, but I'm not sure I understand why). > > Thierry > > Le 25/06/2014 20:20, phil(a)highoctane.be a Ã©crit : >> Maybe due to some Annoucement being picked up by Nautilus? >> >> Phil >> >> >> >> On Wed, Jun 25, 2014 at 7:57 PM, Johan Brichau <johan(a)inceptive.be >> <mailto:johan@inceptive.be>> wrote: >> >> Hi, >> >> It seems that when even a single Nautilus system browser is open and >> you do a load (using Metacello), there is a huge amount of objects >> that get created and persisted in the image. >> This even leads to the point that the image crashes when I try to >> load our code using a ConfigurationOf. After some time, the Pharo >> process is stuck at 100%, image size is over 500MB and the entire >> image becomes unresponsive, finally crashing after an hour or so. >> >> I have not yet found which objects or why, but I just wrestled with >> this all day to find out what was going on. I first thought that >> Metacello was in an infinite loop but after noticing that the image >> was so large (500MB) and that it got reduced to 20% of its size >> after closing the browser window, I can say that Nautilus is >> gathering garbage. It is definitely not Metacello because I can >> trigger the same problem doing a load via Monticello only. >> >> When I load the ConfigurationOf without a single browser open, it >> loads 5x faster and the image size stays reasonable. >> >> Is this a known issue? Any thoughts on what may be causing this? >> >> regards! >> Johan >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 26, 2014