On 26 Jun 2014, at 15:17, Johan Brichau <[email protected]> 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 <[email protected]> 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, [email protected] a écrit : >>> Maybe due to some Annoucement being picked up by Nautilus? >>> >>> Phil >>> >>> >>> >>> On Wed, Jun 25, 2014 at 7:57 PM, Johan Brichau <[email protected] >>> <mailto:[email protected]>> 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 > >
