Skip to main content

[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.





Back to the top