Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Scalability problems

Please find my comments inline.
 
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alex Chapiro
> Sent: Wednesday, October 22, 2008 4:23 PM
> To: CDT General developers list.
> Subject: 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. 

I don't quite understand what you mean. The
CNavigatorProblemsLabelDecorator has nothing to do with the outline
view.

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

Thanks for the pointer. Good to know. So, the trade-off is perhaps 100
elements rather than 500, but I guess this won't make a big difference
anyway. The scalability issues start with thousands or tens of thousands
of elements.

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

What do you mean by "regular mode and 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 :-). 

DecoratingJavaLabelProvider is used in the Package Explorer and other
JDT views, but not in the Project Explorer.
BTW, the DecoratingJavaLabelProvider is based on the
DecoratingStyledCellLabelProvider which is also used in the Common
Navigator.
The JDT content extensions to the Project Explorer use the
JavaNavigatorLabelProvider and this one creates the same scalability
issue with updating problem decorations as CDT (but without workaround).
See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=194209

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

True, the C/C++ Project view does show this scalability problem.
The reason is that it uses a ProblemTreeViewer which has an efficient
way to tell whether a specific resource is represented in the view or
not and its sole purpose is to address this scalability issue with
problem markers.
The Project Explorer does not use a ProblemTreeViewer and it is also not
straightforward to adopt that strategy due to the generic nature of the
Common Navigator framework.

Toni

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


Back to the top