[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Scalability problems
|
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
>
