I reported it as bug 13422 [1]. For now, I was only able to do a comparison before/after which instances are being kept around.
Johan [1] https://pharo.fogbugz.com/default.asp?13422#104139 On 26 Jun 2014, at 16:33, Johan Brichau <jo...@inceptive.be> wrote: > Nicolai, > > It's not a public configuration and it loads quite some packages. > I will pick up this issue this evening to get a better reproducible case. > > thx > Johan > > On 26 Jun 2014, at 16:03, Nicolai Hess <nicolaih...@web.de> wrote: > >> 2014-06-26 15:37 GMT+02:00 Goubier Thierry <thierry.goub...@cea.fr>: >> >> >> Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit : >> >> >> On 26 Jun 2014, at 15:17, Johan Brichau <jo...@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 >> >> >> >> I can not reproduce this, neither the crash nor the image memory blow up. >> I tested several ConfigurationOfXXX, with one or more open Browsers. >> >> Can you tell me what Configuration you are trying to load and if this is a >> fresh pharo image or >> are there any other packages loaded. >> And do you have any Nautilus plugins enabled? >> >> regards >> Nicolai >
