Community
Participate
Working Groups
Build ID: I20090611-1540 Steps To Reproduce: 1. Open java.util.regex.Pattern in the Java editor, with JRE source attached 2. Use Ctrl-O and try to search for any class member More information: Opening the Outline view and using the search filter takes several seconds on every single keypress. Admittedly this file is over 5000 lines long (in my JRE at least), but perhaps it would be a good one for eclipse's performance test suite?
I just tried it on R3.5 and 3.6 M1 and I can't see any delay. Can you please try again using a plain Eclipse SDK and fresh workspace?
Just tried 3.6M1 (I20090806-1400), clean eclipse install and clean workspace. It's about 6 seconds to open the Outline popup, and about 2 seconds on each keypress to filter I'm running Sun jdk1.5.0_15, and the java source is attached from src.zip. The machine has an Intel E6750 with 2GB RAM.
>Just tried 3.6M1 (I20090806-1400) Is this the plain SDK or some J2EE package? Please create several stack dumps (see: http://wiki.eclipse.org/index.php/How_to_report_a_deadlock#Getting_a_stack_trace_on_Windows) while waiting and attach them here.
Created attachment 146385 [details] Thread dump when opening editor
(In reply to comment #3) > >Just tried 3.6M1 (I20090806-1400) > Is this the plain SDK or some J2EE package? It's the standard Java build that I downloaded from http://download.eclipse.org/eclipse/downloads/ > > Please create several stack dumps (see: > http://wiki.eclipse.org/index.php/How_to_report_a_deadlock#Getting_a_stack_trace_on_Windows) > while waiting and attach them here. I've attached four files with a selection of thread dumps. Hope that gives you the info you need.
Created attachment 146386 [details] Another thread dump opening editor
Created attachment 146387 [details] Thread dump when opening outline popup
Created attachment 146388 [details] Thread dump when filtering outline view
It looks like mapping the source, especially Util.getInputStreamAsCharArray is slow in your setup. Moving to JDT Core for further comments.
Are you using a network drive ?
No, it's a local disk.
Satyam, could you please see what could be done there?
Shaw, I could not reproduce the slowness on my machine and I don't understand the slowdown either. The source is generally read and cached so that at least the subsequent actions are at least fast. As, I understand from your comments, even subsequent actions also cause the slowdown. 1. Hence if you could try running eclipse with debug options could help. Here are the instructions to get the debug options: Create a file called .options in the eclipse folder with the following lines in it. ###### org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/buffermanager=true org.eclipse.jdt.core/debug/javamodel/cache = true org.eclipse.jdt.core/debug/javamodel = true ###### Then run eclipse as %eclipsec.exe -debug Please give the output of the command. Please also attach the file .metadata/.log located in your workspace. 2. There seems to be some improvements done by Sun in SingleByteDecoder http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6746334. This could potentially improve the performance. Could you try using any other JVM above 1.6 u12? 3. BTW, What is the encoding of your project?
Can you please respond to any of the questions in comment 13?
If the problem is still there, please reopen this bug with the additional information requested in comment 13.
Verified for 3.7M1 using build I20100802-1800.
