Community
Participate
Working Groups
Eclipse : 3.1M5a Guessing the parameter values in JDT has gone very slow. I have noticed this since 3.1M4. My settings are : Java Editor Code Assist Advanced [x] fill argument names [x] guess names When I turn-off 'guess' method completion & filing in input-parameter name is faster. The plugin project has about 150 Java files and depends on about 20 plugins (not a large one). What other data I can provide to debug this help?
Do you write 1.4 or 5.0 code?
> Do you write 1.4 or 5.0 code? 1.4 code (JRE : sun 1.4.2_02 hotspot)
>I have noticed this since 3.1M4. Do you mean you already saw the problem in 3.1 M4 or was performance OK there? Tom, did you add code for 5.0 which might have slowed down this?
I added parameter guessing for primitive types, but that should not have made such a big difference!
Can you guys reproduce the problem? Is there any other setting I can try? any test data I can produce?
(In reply to comment #3) > >I have noticed this since 3.1M4. > Do you mean you already saw the problem in 3.1 M4 or was performance OK there? Performance on M4 is just as slow like M5a
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
*** Bug 87476 has been marked as a duplicate of this bug. ***
This only happens on one paticular project I am working on. Every where else it works fine & snappy. So I am inclined to close this as 'not reproduceable'. Any other ideas? Can I provide any info about the project, that could be helpful?
It invariably happens on *all* my projects. The least I can say is that I can easily reproduce it! Regards Cyril
Looks like it depends on the project setup and/or content. It would be great if one of you can provide a test project where we see the problem.
1. For M5a, the following changes have been made: a) primitive type support (so a 'short' is allowed for an 'int' parameter) b) autoboxing support (only in Java5 code, allow java.lang.Integer for an int param) 2. There have been no changes between 3.0 and 3.1M4 Since you both state that you see the slowdown since M4, the reason for such a slowdown must be somewhere else.
Sujee, would it be possible to attach a project / workspace that exposes that problem? I cannot reproduce here - there may be a delay of almost up to a second under certain circumstances, but this is nothing compared to the 30s to 4m that Cyril reported. Also, Sujee, what are the worst case delays that you experienced?
*** Bug 87985 has been marked as a duplicate of this bug. ***
I'm able to reproduce it consistently -- that is, once a particular file starts showing the issue, if I go erase and retype what caused it it will do it again. I've outlined a minimal reproduction scenario in Bug 87985 which was able to demonstrate a brief CPU spike of only a few seconds. The file I originally found this on is unfortunately not a good repro scenario (1200 lines, many dependencies, copyrighted) but there the IDE locked up for a solid minute.
Cannot reproduce given the steps in bug 87985. Note that code assist may need some memory, so if you are running on the default 64m heap size, you will very likely cause some gc'ing to occur. Also, repeatedly invoking code assist is usually faster, as the completions may be cached internally. However, comment 15 says that the scenario from bug 87985 is repeatable even when just deleting the code and re-invoking code assist.
FYI, I'm also able to reproduce this if I pretend to develop on a third-party open source class such as org.apache.commons.beanutils.BasicDynaClass. I've already got all its dependencies in my workspace, so I just create a new class in the default namespace and paste the code in. I add some import statements to make the names resolve. I reopen the editor with the argument name guessing enabled and start typing in some method body, adding a call to a method on some aggregate member. I've found that this problem seems to occur most if: - The class has at least one member which is a Map. A Collection might also reproduce it, but I haven't tried. - That Map is being used in the older, non-generic style. That is, something like private Map myMap = new HashMap(). - I'm adding a call to a method such as put(Object, Object) which takes at least one Object argument. - The bigger and more complex the class, and the more dependencies, the more severe the problem. It might also depend on how full the project's overall type database is. Maybe try it out in the Eclipse codebase itself?
re : <a href="#c13">comment 13</a> > sorry, I can not attach my project b/c it is big & proprietary ! I created another sample project, but I can not reproduce the problem there *sigh* I agree with <a href="#c17">comment17</a> from Micheal. This becomes aparent in methods that take an Object as an argument.
Indeed most of my classes have at least a Map or a List as attribute. I cannot use generics, because I must use an old JDK: 1.3.1 or sometimes 1.4.2, depending on the projects---but never 5.0 because we need source-compatibility towards old platforms (production machines still run 1.3.1) Best regards Cyril
*** Bug 90133 has been marked as a duplicate of this bug. ***
I have added a performance instrumentation to eclipse which should help us find out where the problem lies. Try the following: start eclipse like this: $ eclipse -debug <optionsfile> [other parameters] where <optionsfile> is a file containing the following line: org.eclipse.jdt.ui/debug/ResultCollector=true Please post the console output right after you have experienced the huge delay. This will help us to track down the culprit for slow parameter guessing.
Note that the instrumentation will be in the next integration build (I20050405)
This looks like the same issue as #75153. Btw, I just verified that the problem exists in 3.1M6. I will attach very simple project that demonstrates the problem in a second.
Created attachment 19514 [details] trivial project that demonstrates the problem To beef up number of classes I've added *all* plugins from Eclipse installation as dependencies ;-). From my 75153 investigation I believe there is a threshold number of jars or (classes on classpath?) after which the problem appears. Let me know if you need access to my workspace or any other help with this bug which annoys me badly.
Can reproduce with the project provided in comment 24. Investigating.
The problem had not to do with code assist at all. When matching types, we do IJavaProject.findType for the occuring types. This resulted in a exhaustive (and repeated) search for primitive types in the entire project, which took forever if the type did not exist (e.g. primitive types). We used to have an early return for primitive types, but apparently we had removed it. The fix is to not search for types that are known to be unfindable. Fixed > 20050407. Parameter guessing still imposes a sometimes noticeable performance impact when completing method proposals. We are looking into moving to the new jdt-core performance infrastructure to improve even more. Delays up to a couple hundred of milliseconds a second are possible if you happen to miss type caches or trigger a GC. Any delay with a magnitude of seconds (or minutes, as some reports) should be gone.
That's really great! Thank you Tom. I'll try that ASAP.
Tom can you give me some numbers for the percentage speedup? I would like to report this on the performance page.
*** Bug 75153 has been marked as a duplicate of this bug. ***
Test setup: box= fedora core 3 on a Intel(R) Pentium(R) 4 CPU 2.66GHz with 1GB of RAM scenario= see comment 24 eclipse= I20050414 (with/without fix) dimension= Avg time spent in parameter guessing, n= 10 w/o fix: 5013.09ms (stdev: 241.08) with fix: 25.86ms (stdev: 15.44) Speedup: 193.88 Note that this is only the time spent for parameter guessing. In the 'fix' case, the total time until the proposals are displayed averages 78ms, so parameter guessing accounts for about one third of the total time spent. In the 'nofix' case, parameter guessing obviously dominates the total content assist time. The speedup resulting of this fix for the total time spent in content assist is 66.08.
*** Bug 92222 has been marked as a duplicate of this bug. ***
I've tried the feature for a few days without experiencing past delays. Thank you very much Tom, for your excellent work. Best regards, Cyril
*** Bug 93161 has been marked as a duplicate of this bug. ***
house cleaning
