Le 26/06/2014 15:25, Sven Van Caekenberghe a ��crit :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 :)).
On 26 Jun 2014, at 15:17, Johan Brichau <johan@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.
Not by much.
Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower.
I disagree with you there.
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.
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