Comment 1 Igor Fedorenko 2002-04-10 12:55:52 EDT

Created attachment 571 [details]
Example project

Comment 2 gavlin 2002-04-10 18:44:17 EDT

I also have weblogic.jar on my classpath and am experiencing the same problems. 
Build 0328 opened large or small files in the Java Editor in < 2 seconds. 
Builds 040x require 15-30 seconds to open even the smallest files. During the 
wait, the CPU is pegged 100%. The new builds are unusable in this state.

Comment 3 Philipe Mulet 2002-04-11 09:50:46 EDT

Several issues here... currently, even when disabling temporary problems in 
editor, the infrastructure still computes them. We will make sure not to do so 
anymore (which should bring you back to previous performance if no problem is 
displayed).

We still need to optimize the computation of these problems (looks like it is 
causing some heavy cache flushing - due to the nature of the compiler name 
environment used there - SearchableEnvironment against the JavaModel).

Looks like UI also did perform tons of unnecessary refresh (this should be 
improved in today's integration build too).

Keeping this bug open until we have decent performance on big files with error 
detection enabled.

Comment 4 gavlin 2002-04-12 10:26:12 EDT

I downloaded the 20020411 build last night and experienced minimal if any 
performance improvement. Note: I was running w/"temporary problems" disabled.

Comment 5 Kim Rasmussen 2002-04-14 05:02:02 EDT

I think that the performance slowdown has everything todo with the number of 
classes in the projects build-path.

With weblogic.jar (which is about 25 megs) in the buildpath, it easily takes 30 
seconds with 100% CPU to open a file containing a servlet.

Code-assist is also equally unusable for such files - 20-30 seconds of 100% CPU 
to process a "this.<ctrl-space>"

If I remove weblogic.jar from the classpath and replace it with servlet.jar 
from tomcat (40K) then it takes less than a second to open the file.

Unfortunately, it makes builds >= 20020404 pretty much unusable it you are 
forced to have large .jar files in your build path.

I have tried playing around with the settings in the editor that have to do 
with parsing the file, but I didn't find anything that makes a difference.

Comment 6 oliver jehle 2002-04-15 08:03:05 EDT

>currently, even when disabling temporary problems in 
>editor, the infrastructure still computes them. We will make sure not to do so 
>anymore (which should bring you back to previous performance if no problem is 
>displayed).

can you tell when this workaround will be fixed (build ??)  ???? 

Comment 7 Kim Rasmussen 2002-04-15 09:36:35 EDT

Is it too late to get it in M5 ? In reality, it makes Eclipse nearly unusable, 
since I have projects that depend heavily upon the weblogic.* classes.

Not getting this fixed in M5 would really mean I have to wait for M6, and keep 
using M4 until then.

Comment 8 Philipe Mulet 2002-04-15 10:29:36 EDT

As soon as we have a good fix for this one, we will post it as a patch for M5 
on the JDT/Core dev page.

For M5, we did ensure that the editor would not attempt to compute errors if 
explicitely told not to (temporary problems setting).

Now on the good new, we think we know what is going on. The JavaModel cache 
isn't able to scale to address large workspaces, containing more than a 1000 
packages at once. It will enter a mode where every single Java operation is 
really expensive... we are working on a patch, and we plan to post it asap to 
get some feedback.

Comment 9 Kim Rasmussen 2002-04-15 12:49:32 EDT

Great, as long as I can turn it off in the settings, I can use it.

Thanks.

Comment 10 Philipe Mulet 2002-04-15 12:57:34 EDT

A performance patch is posted on Jdt/Core resource dev page.
Feedback would be much appreciated.

Link to patch: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core-
home/org.eclipse.jdt.core239b.zip

Comment 11 gavlin 2002-04-15 13:05:33 EDT

Philippe, am I correct that the ">1000 packages in workspace" performance 
problems experienced in all 040x builds thus far will only appear in M5 if 
the "temporary problems" setting is enabled?

Comment 12 Kim Rasmussen 2002-04-15 13:10:02 EDT

Since M5 isn't available yet, I applied the patch to the latest integration 
build (0412).

Apart from an entry in the errorlog first time I restarted eclipse, it seems to 
work perfectly.

I have included the entry from the error-log, but it only occured the first 
time I restarted, not subsequent times.

<log-entry date="Mon Apr 15 20:11:57 CEST 2002">
  <status
     plugin-id="org.eclipse.ui"
     severity="WARNING"
     message="Problems occurred when invoking code from plug-in: 
org.eclipse.ui."
     code="2">
    <exception
       message="org.eclipse.jdt.internal.core.Buffer"
       trace="
java.lang.ClassCastException: org.eclipse.jdt.internal.core.Buffer
        at 
org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.createEle
mentInfo(CompilationUnitDocumentProvider.
java:429)
        at org.eclipse.ui.texteditor.AbstractDocumentProvider.connect
(AbstractDocumentProvider.java:247)
        at org.eclipse.ui.texteditor.AbstractTextEditor.doSetInput
(AbstractTextEditor.java:1503)
        at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.doSetInput
(JavaEditor.java:479)
        at 
org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSetInput
(CompilationUnitEditor.java:932)
        at org.eclipse.ui.texteditor.AbstractTextEditor.init
(AbstractTextEditor.java:1146)
        at org.eclipse.ui.internal.EditorManager.createSite
(EditorManager.java:485)
        at org.eclipse.ui.internal.EditorManager.access$1
(EditorManager.java:483)
        at org.eclipse.ui.internal.EditorManager$2.run(EditorManager.java:467)
        at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:56)
        at org.eclipse.ui.internal.EditorManager.openInternalEditor
(EditorManager.java:460)
        at org.eclipse.ui.internal.EditorManager.openInternalEditor
(EditorManager.java:529)
        at org.eclipse.ui.internal.EditorManager.access$3
(EditorManager.java:524)
        at org.eclipse.ui.internal.EditorManager$5.run(EditorManager.java:636)
        at org.eclipse.core.internal.runtime.InternalPlatform.run
(InternalPlatform.java:838)
        at org.eclipse.core.runtime.Platform.run(Platform.java:411)
        at org.eclipse.ui.internal.EditorManager.restoreState
(EditorManager.java:590)
        at org.eclipse.ui.internal.WorkbenchPage.restoreState
(WorkbenchPage.java:1708)
        at org.eclipse.ui.internal.WorkbenchPage.&lt;init&gt;
(WorkbenchPage.java:308)
        at org.eclipse.ui.internal.WorkbenchWindow.restoreState
(WorkbenchWindow.java:940)
        at org.eclipse.ui.internal.Workbench.restoreState(Workbench.java:794)
        at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:632)
        at org.eclipse.core.internal.runtime.InternalPlatform.run
(InternalPlatform.java:838)
        at org.eclipse.core.runtime.Platform.run(Platform.java:411)
        at org.eclipse.ui.internal.Workbench.openPreviousWorkbenchState
(Workbench.java:610)
        at org.eclipse.ui.internal.Workbench.openWindows(Workbench.java:667)
        at org.eclipse.ui.internal.Workbench.init(Workbench.java:503)
        at org.eclipse.ui.internal.Workbench.run(Workbench.java:816)
        at org.eclipse.core.internal.boot.InternalBootLoader.run
(InternalBootLoader.java:777)
        at org.eclipse.core.boot.BootLoader.run(BootLoader.java:319)
        at java.lang.reflect.Method.invoke(Native Method)
        at org.eclipse.core.launcher.Main.basicRun(Main.java:190)
        at org.eclipse.core.launcher.Main.run(Main.java:549)
        at org.eclipse.core.launcher.Main.main(Main.java:390)
">
    </exception>
  </status>
</log-entry>

Comment 13 Philipe Mulet 2002-04-15 14:22:48 EDT

I have seen this dump in the error log as well. Will see with JDT/UI who's 
responsible for it. Thanks for the feedback.

Comment 14 Kim Rasmussen 2002-04-15 16:39:19 EDT

hmm... you should be careful about applying the patch - I got some weird errors 
after applying it to the integration build 20020412.

Basically, after applying it my .java files were never saved to the disk. 
Eclipse claimed to have compiled them, but they never ended up getting saved to 
the disk, so it took me a little time to track down why my changes were lost 
when I used ant to build outside of eclipse.

Comment 15 oliver jehle 2002-04-16 02:25:14 EDT

after patching integration build 1204 motif-linux i can work with the
weblogic.jar in the build path !!!!!

i also checked the disk-saved objects and the commited cvs objects and they are
all saved !!! 

we will test it under windows2000 today... 

Comment 16 Morten Wilken 2002-04-16 05:22:16 EDT

i too applæied it to build 20024012 and experienced that my .java files was'nt 
saved.

Comment 17 oliver jehle 2002-04-16 07:16:28 EDT

i'm sorry for my last posting... 

i applied the patch to integration build 1104... not as posted soon 1204 

with build 1104 and the patch, the linux-motif and windows version work. if you
change a java object and save it, its written to the filesystem. 

Comment 18 Philipe Mulet 2002-04-16 07:26:07 EDT

We think we have resolved the other issues as well (ClassCastException + 
unsaved changes). Along with the performance patch, we fixed a leak in the 
buffer caching, which would cause it to keep closed buffers. 

When fixing this, closed buffers were gone, but reaccessing such a buffer would 
cause the buffer type to become wrong and misbehave from there on. Buffer 
closing opens when overflowing the buffer cache.

Improved patch 239c got posted on Jdt/Core resource dev page.

Fixed.

Comment 19 Martin Aeschlimann 2002-04-17 03:44:44 EDT

*** Bug 13468 has been marked as a duplicate of this bug. ***