[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-dev] Eclipse CDT performance (with NX)
|
Hi James,
When eclipse got slow I tried to profile it using jvisualvm without much success :(
Before I took the thread dump I restarted jvisualvm so it should have stop the profiling, am I right?
I'll be at my office on Sunday and will be able to do additional tests. Did you see anything suspicious in the dump thread?
Thanks,
Yevgeny
* From: James Blackburn <jamesblackburn@xxxxxxxxx>
* Date: Thu, 3 Jun 2010 19:00:57 +0100
* Delivered-to: cdt-dev@xxxxxxxxxxx
* Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Kw6Br3gQ0jPW7UdpEdW2sy1VGF2DareWBRaYtOZOEFY=; b=DdyPLH69C0G84lh3ay+CjUDmBpinxgfF21/Csa6x6gWW/JmvFrii0RyQPKw5fnmYq3 uwb9QmBJ0z6smjwTGmXz1KqDWB89go1do8+PvGk4q84haoxjxqoclb6GMZUgRNYE9cb4 oi8qdZWnXXiFLFIblYCE2FPxmhELKpIfFenOc=
* Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=OV9uaG3HQQ6TbTlS/FIknv2n5rtp+60BKROalFQspDl0sh//0b+2av887smenikC1f RK8yROcWXoTqMWD5+Sp8+gtoyEIOCqJsns0y3Iqdotgk7bl/yk9inEQCGmdGnrKwlWrB JPCGinf/g+ak/8p1QIAIILLRLcTwNYGfykUAs=
Is that not an artifact of trying to profile the running eclipse using
jvisualvm? Do you see these even if you don't try to profile it?
James
On 3 June 2010 18:52, Yevgeny Shifrin <Yevgeny.Shifrin@xxxxxxxxxxx> wrote:
> 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
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
