On Thu, Oct 23, 2008 at 4:22 AM, Leherbauer, Anton
<Anton.Leherbauer@xxxxxxxxxxxxx> wrote:
Please find my comments inline.
> 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.
I think this is PR87027, but I'm not sure now.
What do you mean by "regular mode and bulk mode"?
"Bulk mode" I mean massive workspace update. If user starts such operation as import of large number of projects, "rude workaround can be activated. Then after the import finish it can be switched back. I tried this, it worked. But to implement it I had to breake API by adding enableBulkMode(boolean enable) method to
CNavigatorProblemsLabelDecorator.
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
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.
You are absolutely right. Yesterday I more deeply looked up to this code and understood this details. Looks like Project Explorer being build on the navigator engine is incurable from the bad scalability problem.
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
> >
> >
