[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cdt-dev] Scalability problems
|
I'd like to discuss (if of course there is somebody who could be interested in
that topic) the performance and scalability problem in CDT using an example of
import of huge number of projects.I found in Bugzila couple of PRs about that
(91035 and 154691), both unresolved. In our commercial product based on CDT, we
also for a long time have been experiencing problems of this type (import to WS
more than 1 G of source code is a good example). Actually I see two main
"troublemakers".
1) Very intensive, unproportional (if you compare it with really visible area of
resource tree) flow of label decoration requests to UI. It is typical for
Project Explorer only. C/C++ project demonstrates "good behavior". (The picture
is more complex than I describe it now, I just skip the complexity). The good
remedy for that turned out to be very simple. In
CNavigatorProblemsLabelDecorator class:
protected void fireProblemsChanged(IResource[] changedResources,
boolean isMarkerChange) {
super.fireProblemsChanged(null, isMarkerChange);
}
If somebody is curious why it is harmless and why it works, I can explain my
understanding of the issue). Admittedly, I feel a bit uncomfortable with this
solution: it seems to be a sort of hack. I found more legal solution, but it's
not so effective :-((
2) Bad responsiveness of UI. The solution in my oppinion is a combination of two
things. On one hand programmer to achieve reasonable responsiveness of UI should
follow some general rules ( see for example
http://www.eclipsecon.org/2004/EclipseCon_2004_TechnicalTrackPresentations/39_Arthorne-Lemieux.pdf
).On the other hand I see essencial reserve of improvement in CDT Model. In
particular I'd like to split cumbersom procedure opening of CElement (see
especially CProject opening) to "light open" (which model does always by
default) and "full open" (including reading bulk stuff from file system),
implicitly processed when it ends up to be necessary. It doesn't requy changing
of API, I suppose.
So two questions:
a) If somebody has such huge import problem, could you please try the first
solution.
b) Light and full open for CProject: does it seem to be reasonable? Are there
more effective proposals to improve performance in this area?
Sorry for the long text
Alex.