Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Scalability problems 
Thank you for you reply,
I know about this workaround because I proposed it long time ago :-) Actually the purpose of it was to avoid big overhead in outline (it was extraordinary in some cases). This new one seems to be more aggressive. However I guess it doesn't lead to full viewer refresh. If you look at AbstractTreeViewer.labelProviderChanged which is invoked in this case, it redraws only visible elements. This is not so expensive. Of course, this is primitive solution without changing of API. However it could be improved by implementing to different modes : regular mode and bulk mode bulk mode.
As I see now, implementation of Navigator engine is a bit weird. Indeed if you have JDT installed, it starts before C/C++ project explorer and initiates its own label provider instead of default one: DecoratedJavaLabelProvider. This one has more sophisticated implementation (it processes UI requests using queue, something like discussed here: http://www.eclipsezone.com/eclipse/forums/t105450.html ). In this case everything works well (without my hack :-). More promising: it works just perfect if you close Project Explorer and open C/C++ Projects view instead. There is an explanation and I guess, the way how to fix the whole problem. Like JDT this viewer uses its own label provider DecoratedCLabelProvider which works as fine as its JDT "colleague". In project explorer I tried to replace default label provider with this good one, but had a mixed result. I'm not give up and try it later. 


On 22/10/2008 5:23 AM, Leherbauer, Anton wrote:

Hi Alex,


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.


This is a well-known problem.
On the one hand, there is already a workaround in CDT which tries to
make a trade-off between individual item updates and a complete viewer
refresh:

protected void fireProblemsChanged(IResource[] changedResources,
			boolean isMarkerChange) {	
	// performance: if the number of changed resources is large, it
is faster
	// to trigger a viewer refresh by setting changedResources to
null
	if (changedResources != null&&  changedResources.length>  500) {
		changedResources= null;
	}
	super.fireProblemsChanged(changedResources, isMarkerChange);
}

Your suggested change would lead to an unconditional viewer refresh even
if only one item needs an update. This is also not so good
performance-wise. A complete refresh can be very expensive, too!

On the other hand, even with this workaround, there is still the problem
that the JDT contribution to the Project Explorer also tries to update
the label decorators and triggers the same performance problem again.
I have filed a bug against JDT for this, although it needs to be solved
in the Project Explorer / Common Navigator framework.


b) Light and full open for CProject: does it seem to be
reasonable?


If you can make CProject.open() less heavyweight, I am all for it!

Cheers,
Toni


-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alex Chapiro
Sent: Tuesday, October 21, 2008 10:35 PM
To: CDT General developers list.
Subject: [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_TechnicalTrackP
resentations/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.



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top