Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-dev] [m2e-users] M2Eclipse Performance (Was: Having a Bad Week - eclipse sick) 
m2e-core master.

Snjeza

Fred Bricon wrote:

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 <mailto: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 <mailto:m2e-users@xxxxxxxxxxx>
        https://dev.eclipse.org/mailman/listinfo/m2e-users


    _______________________________________________
    m2e-users mailing list
    m2e-users@xxxxxxxxxxx <mailto:m2e-users@xxxxxxxxxxx>
    https://dev.eclipse.org/mailman/listinfo/m2e-users




--
"Have you tried turning it off and on again" - The IT Crowd

Back to the top