[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2e-users] M2Eclipse Performance (Was: Having a Bad Week - eclipse sick)
|
Great work Snjeza!!! What branch are you using?
Maybe one patch per change would be easier to track.
Fred Bricon
2011/4/12 Snjezana Peco
<snjezana.peco@xxxxxxxxxx>
I have tested m2eclipse performance.
These are my first impressions:
1) ProjectRegistryRefreshJob changes a workspace and fires a lot of resource change listeners.
When creating a marker, for instance, this job fires five resource change listeners (createMarker and four the setAttribute methods).
This job should be WorkspaceJob.
2) ProjectRegistryRefreshJob and MavenBuilder (a builder job) aren't synchronized what often causes StaleMutableProjectRegistryException (ProjectRegistryManager, line 319) and that is the cause of starting this job again.
3) LifecycleMappingFactory.getBundleMetadataSources is too often called. Every time it is called it reads the extension point registry and lifecycle mapping xml files. Caching would speed up the overall performance.
4) The BuildPathManager.configureAttchedSourcesAndJavadoc method is very slow. I have improved it a little (DownloadSourcesJob isn't started when the download preferences are off), but it is possible to improve it more.
5) NexusIndexManager.mavenProjectChanged(...) always removes and adds back an artifact to the index repository. Performance will be much better if the index repository is updated only when the artifact doesn't exist or is changed. Searching the index repository is much faster than removing and adding artifacts.
6) MarkerLocationService.addEditorHintMarkers calls two methods that acquire the WTP's IDOMModel (StructuredModelManager.getModelManager().getModelForRead(...)) and release it. WTP's methods can be slow for larger files and it would be better to acquire/release the model once for MarkerLocationService.addEditorHintMarkers.
MarkerLocationService.addEditorHintMarkers is used only once.
7) ProjectRegistryManager.applyMutableProjectRegistry calls stateReader.writeWorkspaceState(projectRegistry) when refreshing a project. Since the workspaceState.ser file is only used when starting a workspace, this method can be used only when stopping the org.eclipse.m2e.core bundle
8) BuildPathManager.mavenProjectChanged updates Maven classpath containers of all projects no matter they are changed or not. They should be updated only for relevant events (event.getFlags() != 0).
9) ProjectRegistryManager.refresh(MutableProjectRegistry newState, DependencyResolutionContext context, IProgressMonitor monitor) aggressively
read Maven projects.
I have tested JBoss AS 7 (https://github.com/jbossas/jboss-as). When calling Maven>Update Project Configuration on the jboss-as-parent project, the MavenImpl.readProject is called for about 2-6 times for each project in the workspace. Sometimes this method lasts short time (Maven cache is active), but sometimes takes a longer time.
I have tried to cache MavenProjectFacade in each of the two phases so that MavenImpl.readProject is called two times for every project (once per each phase). Not sure if it is possible to make this method to be run only once.
10) The Maven Pom Editor has a huge memory leak. Just opening/closing jboss-as-parent/pom.xml will cause the JVM heap size to increase by 2-10MB which can cause Eclipse to crash (OOM).
I have implemented 1-9 enhancements. The Maven>Update Project Configuration action on the jboss-as-parent project is much faster (2-3 times). Editing the pom.xml file of the jboss-as-parent project is 2-3 times faster. The Maven builder is improved 2-3 times.
Would you like me to create a patch?
Snjeza
Snjezana Peco wrote:
Hello Steve,
I would like to test this a bit more. Could you provide me with more details?
Steve Cohen wrote:
and, sad to say, it's mostly because of the combination of m2eclipse, helios, subversive and the whole fracking mess.
Eclipse has become less and less usable. I don't know who's to blame, which plugin is the cause or whether it's the whole platform or some combination. Rare is the day of heavy development where Eclipse doesn't crash many times.
Every crash is different. Sometimes I have to delete the .lock file. Other times I don't. Other times I can't do it without killing processes.
Could you check if there are files named hs_err_pidXXXX.log in your working directory (your ECLIPSE_HOME probably)?
If so, could you attach any of them?
eclipse-jee-helios-SR2
m2eclipse, whatever the latest that's available today
subversive
hibernate plugin
Could you attach your configuration : Help>About Eclipse SDK>Installation Details>Configuration
There are still user interface actions that provoke crashes.
What actions are causing the crash? Editing pom.xml, cleaning the project, svn checkout/merge or something else.
Thanks,
Snjeza
_______________________________________________
m2e-users mailing list
m2e-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-users
_______________________________________________
m2e-users mailing list
m2e-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-users
--
"Have you tried turning it off and on again" - The IT Crowd