[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Eclipse CDT performance (with NX)
|
On 3 June 2010 21:10, Yevgeny Shifrin <Yevgeny.Shifrin@xxxxxxxxxxx> wrote:
> 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?
Nope. jvisualvm messes up your Eclipse's java forever more. I've not
had much success using it for profiling eclipse, try running the Java
with profiling enabled:
-agentlib:hprof=cpu=samples
James
>
> 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
>>
>>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
