Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit :
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.
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
