Our company is using eclipse since several years now (we are using WTP since release 0.7)
I am currently evaluating eclipse 3.6.2 with WTP 3.2.3 which s
To answer the following question: Do you have some best practices to speed it up, especially for upper-mid-sized like ours?
Turning off validation and auto-building after file-saving is a good start to increase performance.
If you need barebones Java EE then you are better off with Netbeans, if you need everything but just working you are better off with IDEA. It is as simple as that.
We have the same problem with WTP 3.2.3 here, too. We use it in our product for several years, too but the acceptance of our developers and customers in this tool is decreasing every year because in every newer release it is slower and slower.
I would like to use it if I could disable all "advanced" features but as you mentioned you cannot disable the indexers at all. Also you cannot stop the validator of JSP files if it is already running (you can test this if you have that many files as you have and we also have around 1000 JSP files and many tag files in our project).
I also can prove that increasing the memory does not help. It only prevents crashes of the whole eclipse but it does not reduce the UI blocking internal operations of WTP.
In the newest version 3.2.3 I got many hangs when I start Tomcat from within the servers view. The UI just hangs about 1 minute. It's not only me who has the hangs, it's all my colleagues who work on Windows have the same problem. On Linux I do not know about this problem.
Also there are problems in WTP when you have no access to the internet. It seems there are request to some registries to download schemas or such things and if you do not have a connection then it just hangs and waits for the time out.
I also think the stability and performance of Eclipse/WTP is somewhat alarming. I'm using Eclipse since mid 2003 and have been trying WTP since its very first releases.
At first the quality was absolute abysmal, but for a 0.x version I couldn't complain of course. While waiting for WTP to mature, I used MyEclipse, which was sort of okay but had its flaws too (and being partially based on WTP, inherited some of WTP).
When MyEclipse became heavier and heavier, slower and slower and we ran into several stability issues, we switched to 'pure WTP'. All we were using was really the basic JSP/JSF editor and deployer.
Since WTP doesn't do incremental deployment (at least not for the JBoss server runtime) we added the separate server runtime from JBoss tools. When we adopted Facelets, we also switched to the editor from JBoss tools.
We do however run into a lot of problems we also had with MyEclipse. There are unexplainable slowdowns, but much worse are various stability problems. There are lots of awkward exceptions and crashes. A typical .log file on many different workstations I examined is chockfull of exceptions. A small selection of the last 10 exceptions in my log:
1.
java.lang.NullPointerException
at org.eclipse.jst.jsp.core.internal.validation.JSPActionValidator.isElIgnored(JSPActionValidator.java:147)
2.
java.lang.RuntimeException
at org.eclipse.jface.viewers.ColumnViewer.checkBusy(ColumnViewer.java:763)
3.
java.lang.ArrayIndexOutOfBoundsException: 38
at org.eclipse.debug.internal.ui.viewers.model.FilterTransform$Node.addFilter(FilterTransform.java:67)
4.
org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet 302111.
at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:171)
5.
java.lang.NullPointerException
at org.eclipse.jst.jsf.facelet.core.internal.cm.ElementCMAdapter.getLength(ElementCMAdapter.java:109)
6.
Caused by: java.lang.NullPointerException
at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.WebappConfiguration.getConfigFilesFromContextParam(WebappConfiguration.java:184)
7.
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature 'span' not found. (file:///mysystem/Eclipse.app/Contents/MacOS/com
/sun/faces/metadata/taglib/facelets_jsf_core.taglib.xml, 453, 52)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
...
at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.TagModelLoader.loadFromInputStream(TagModelLoader.java:100)
8.
java.lang.NullPointerException: No IModelProvider exists for project P/my_project of version: Utility Module
at org.eclipse.jst.j2ee.model.ModelProviderManager.getModelProvider(ModelProviderManager.java:101
9.
java.lang.NullPointerException
at org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory.clearCache(J2EEDeployableFactory.java:238)
10.
org.eclipse.jst.jee.model.internal.mergers.ModelException: java.util.ConcurrentModificationException
at org.eclipse.jst.jee.model.internal.mergers.EjbJarMerger.process(EjbJarMerger.java:79)
Note that these are just the last 10, there are many, many more exceptions.
The casual reaction would be: "Your Eclipse install is corrupted! You have a local problem!" Yes, I might have a local problem, but this "local problem" seems widespread as many Eclipse installs I inspected seem to have this stuff in their logs.
I'm also having problems with deployments like reported at the following link in various incarnations: http://community.jboss.org/thread/158611 It may be JBoss tools specific or it may be based on the underlying WTP or even Eclipse code. I don't know, but I do know it's a nasty problem. Every WTP and JBoss tools version there is 'something' fixed, and every version a problem like that resurfaces in a slightly different form.
Between the stability problems I'm able to get some work done and I love the auto completion and navigate-into features the editors offer me (which keeps me from switching to a text editor and building completely on the command line), but I sure would love some increased stability.
To respond, I'm the lead for the projects that supply the JSP, XML, and JavaScript source editing functionality in WTP. The simple fact is that we don't spend much time on performance tests because we lack resources for doing that. Of course we'd like to be proactive about it rather than reactive, but we tend to allocate our time to functional problems first. We do have an adopter product running performance regression tests regularly, but I expect that tests are run on multi-core machines by now--and we haven't had any new red flags reported to us for some time.
Of the 3 bugs you linked to, 2 predate the 3.0.4 version you laud and the third is either a formatting performance issue (since addressed) or one with as-you-type validation specific to XML files (the fixing of which would have triggered a memory leak in Xerces, iirc, hence us not putting it in at that time). If you have concrete projects that you can attach to a bug and say "doing X is slower in 3.2 by Y amount", we'll do what we can to figure out where there's a regression.
As for the indexers, they should at least eventually complete. The on-disk information that is stored has changed between WTP versions, and those files need to be reprocessed so they're again included in search and (where implemented) refactoring operations. Once the initial indexing is complete, it should act incrementally and be virtually unnoticeable. One architectural change you may be running into is that for JSPs, the entire workspace needs to be indexed in a single workbench session for that index to be considered "up to date". Shutting down Eclipse out of frustration will only prolong the impact of that reprocessing.
It sounds like your company's standard install includes the entirety of WTP rather than rolling your own custom distribution. I urge you to check the Startup and Shutdown preference page and turn off early startup of any functionality you're not interested in using. Nothing you've mentioned interest in makes use of that facility, but there are other areas of WTP and the Platform that do. Anything you're not interested in validating is fair game on the Validation preference page, as well as the setting to validate JSP fragments by default on the Web / JSP Files / Validation preference page.
I've disabled the WTP JSP editor for the reasons you mentioned above: It just needs too many resources. Some more things you should consider:
Edit JSPs in the normal HTML editor. That means you don't get code completion which is a good thing. IMO, Mixing Java and HTML is a mistake in the first place and an editor can't fix that. Put all Java code into helper beans (which you can then test easily) and just access the beans from JSP. This should get rid of 99% of all the <% %>
tags and solve most of your problems already.
Consider using Spring to be able to build more complex beans and inject them into your JSPs using these patterns:
Use SpringBeanAutowiringSupport:
<%!
@Autowired
private Bean bean;
public void jspInit() {
SpringBeanAutowiringSupport
.processInjectionBasedOnServletContext(
this, getServletContext()
);
}
%>
Try a different VM. WTP editors creates huge amounts of objects and now all VMs (GC implementations) can handle that equally well. If you use Sun's Java, try JRockit or IBMs J9. Also play with the GC settings. Increasing RAM won't help because if you have GC issues, more RAM usually only makes it worse (since the GC will have to process more data).
Precompile as much code as possible. You don't need 4000 classes open at all times on your workspace. Cut your huge project into manageable chunks.
Replace JSPs with plain Java servlets and use HTML rendering libraries like rendersnake or use a programming language which plays more nice with HTML (like Groovy).
Get some decent hardware. A new PC with a quad core and 8GB RAM costs $1000. If you save ten minutes every day, the investment will be paid up in 50 days (at the rate of 1 person costs $1000/day all in all).
Try MyEclipse which has much better web editors. The JSP editor is better than WTP (code completion works most of the time, for example) but it's still sluggish.