Hi,
In continue to my previous mail about eclipse CDT
performance issues using NX. Currently I am experiencing issue I mentioned in
point 2.4 (below) - eclipse is very slow in NX session. Everything that happens
in NX session is in slow motion. From my experience if I close (or restart)
eclipse the performance issue will be solved. I opened additional NX session to
the same Linux server and opened eclipse with duplication of C++ project opened
in problematic eclipse. On the other session everything works great. Both
eclipse are not performing any visible tasks. I tried looking at both eclipse
instances using Java Visual VM. I attached the 2 thread dumps: thread_dump_1 (problematic
eclipse) and thread_dump_2 (quick eclipse). There is a difference in number opened
threads: slow eclipse ~90, quick eclipse ~20. The following threads appear a
lot in slow eclipse:
"RMI TCP
Connection(242)-147.234.244.132" daemon prio=10 tid=0x00000000531f0800
nid=0x4d39 runnable [0x000000004d4b1000]
java.lang.Thread.State: RUNNABLE
at
java.net.SocketInputStream.socketRead0(Native Method)
at
java.net.SocketInputStream.read(SocketInputStream.java:129)
at
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at
java.io.BufferedInputStream.read(BufferedInputStream.java:237)
-
locked <0x00002aaad88fdb78> (a java.io.BufferedInputStream)
at
java.io.FilterInputStream.read(FilterInputStream.java:66)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:517)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at
java.lang.Thread.run(Thread.java:619)
Locked ownable
synchronizers:
-
<0x00002aaad88f11f0> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
"RMI TCP
Connection(241)-147.234.244.132" daemon prio=10 tid=0x00002aab146a3800
nid=0x4c7e runnable [0x00000000403d6000]
java.lang.Thread.State: RUNNABLE
at
java.net.SocketInputStream.socketRead0(Native Method)
at
java.net.SocketInputStream.read(SocketInputStream.java:129)
at
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at
java.io.BufferedInputStream.read
(BufferedInputStream.java:237)
-
locked <0x00002aaad8905a70> (a java.io.BufferedInputStream)
at
java.io.FilterInputStream.read(FilterInputStream.java:66)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:517)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at
java.lang.Thread.run(Thread.java:619)
Does anyone know why there so many thread like that and
what is their functionality? I would appreciated if experienced eclipse
developers could take a look at these thread dumps, maybe you will see some
problem.
Thanks a lot,
Yevgeny
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of James Blackburn
Sent: Thursday, May 20, 2010 12:12 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Eclipse CDT Performance
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
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev