Ok then, a simple profile should do it. I'll have a look.
I did profile loading Roassal2 with AltBrowser yesterday evening and updates on the browser take 15% of the execution time... Will optimize that.
Thierry Le 27/06/2014 11:58, p...@highoctane.be a écrit :
Same story here. Loading with browsers closed leads to a 10x faster load. Phil Le 27 juin 2014 10:31, "Johan Brichau" <jo...@inceptive.be <mailto:jo...@inceptive.be>> a écrit : > > 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 <mailto: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 <mailto:nicolaih...@web.de>> wrote: > > > >> 2014-06-26 15:37 GMT+02:00 Goubier Thierry <thierry.goub...@cea.fr <mailto: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 <mailto: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 > > > >
-- 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
