Re: [cdt-dev] Eclipse CDT Performance

[James Blackburn <jamesblackburn@xxxxxxxxx>]

Hi Yevgeny,

We're interested in performance too, and keep an eye on low-hanging fruit.
One of the shames is that Eclipse is so large that I don't have access
to a profiler that works. I tried TPTP some time back, it crashed. I
filed bugs which were closed after a couple years as its their policy
to do so...

We also use CDT on NFS with similarly sized projects.

On 19 May 2010 21:14, Yevgeny Shifrin <Yevgeny.Shifrin@xxxxxxxxxxx> wrote:
>        2.2) When indexing / or building is being done if you stop it, it may take almost a minute till the thread / action disappears from the "Progress" view. Similar with build, in our build we call some proprietary build script. It may take almost a minute from the time it shows on the "Console" view that it finished, till the action disappears from the "Progress" view. What does it do all this time? I am not sure if there is an open bug for this.

This is the post-build refresh. We should really get the platform to
add a hook to the refreshmanager to schedule this best effort in the
background. I think it should be an easy thing to get fixed
post-Helios.

>        2.4) Sometimes eclipse becomes very slow (everything works in a "slow motion"), if I restart it the issue is solved. When it happens eclipse is not doing any difficult tasks (indexing, etc.), it does not consume to much memory and when looking at the "top" of Linux server I could not see any reason for this behavior. It does not happen to SlickEdit users. Maybe it relates to point 1.1, hopefully when using local Linux installation this problem will be solved. Has anyone encountered such behavior?

We had one of these recently.  Every action the user performed was
slow. Starting a build, saving an editor, opening files.  He'd been
running Eclipse for a couple weeks and from past experience we knew
that restarting Eclipse fixes the problem.

We run jstack -p <eclipse_pid> in a while loop once per second and the
user attempted to perform actions. The result was that Eclipse was
very busily (5+ seconds a time) updating image overlays spending its
time fetching markers from the platform:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=312232
We have no idea why it was doing that, nor why restarting fixes it,
(but we haven't had a look at the code either)...

In general try to grab back-traces using jstack, jvisualvm, or
whatever's your tool of choice.  For example on Linux you might do
this:
while [ true ] ; do  jstack java_pid > `date "+%Y%m%d.%H%M.%S"` ; sleep 1; done
(replacing java_pid with the pid of eclipse's java).
Which will give you back trace once per second to a separate file.
You can iterate through them to see if there's a common theme.
Hopefully it'd contain what's locking up the main thread / the
workspace / whatever.

One of the rules in the Eclipse concurrency 3.0 presentation:
http://www.eclipsecon.org/2004/EclipseCon_2004_TechnicalTrackPresentations/39_Arthorne-Lemieux.pdf
is that the user should get feedback from any action with 0.1s. Any
longer work should be performed out of the UI thread.

Then file bugs with what you find! I'm sure if you find any big
culprits there'll be many interested parties!

Cheers,
James

> In my opinion the most important for CDT is its performance and not new functionality. If you try QT Creator which currently does not have as rich functionality as Eclipse CDT, you will see how quick and responsive it is.
>
> Although I've been talking about the problems in Eclipse CDT, I think this is a great framework with a big future :)
>
> Thanks a lot,
> Yevgeny_______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>