[jira] Closed: (MNG-3647) Maven performance needs improvement

["Jason van Zyl (JIRA)" <ji...@codehaus.org>]

     [ http://jira.codehaus.org/browse/MNG-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason van Zyl closed MNG-3647.
------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 2.2.x)
                   3.x

> Maven performance needs improvement
> -----------------------------------
>
>                 Key: MNG-3647
>                 URL: http://jira.codehaus.org/browse/MNG-3647
>             Project: Maven 2 & 3
>          Issue Type: Bug
>    Affects Versions: 2.0.8
>            Reporter: Ittay Dror
>             Fix For: 3.x
>
>
> I have a multi-module project with 40 modules. Running 'install' with no compilation takes 30 seconds. Running 'compile' takes 18 seconds. This is very high IMHO. Buildr (written in Ruby - a scripted language) takes 1 second). In 'compile', adding time measurements to the mojo executions showed a cumulative time of 4.8 seconds. (Note that I ran maven several times, so all files are in the buffer cache)
> I've profiled the code to find obvious bottlenecks. Here is what I could easily fix:
> a. reading component configuration: in maven-uber jar there are 9 configurations that maven read and parsed 2394 times. I added a simple HashMap cache to return the already parsed configuration. Note that this suggest a lot of inefficiency in the maven code itself. 
> b. ComponentValueSetter is used to set values in Mojos. It is created per field and always tries to find the field again. This showed high during profiling. I implemented a cache but I'm not sure whether this matters much 
> c. in plexus, component discovery is done a lot of times - every time a jar is added to the container after it is started. this does a lot of xml parsing. I added code to disable component discovery temporarily and start it again. I call it from DefaultLifecycleExecutor.findExtensions at the start and end of the method. Also from DefaultPluginManager.ensurePluginContainerIsComplete.
> d. in DefaultRepositoryMetadataManager the function readMetadata always loads the metadata file and parses it. I have added a cache (although without paying attention to timestamps)
> Also, I ran java with the flags -client -dsa -da -Xnoclassgc -Xbatch -Xincgc.  This shaved 3 seconds.
> All the above steps caused the time to drop to 8 seconds. Meaning 3 seconds due to JVM flags and 7 seconds of actions that could easily be avoided.
> There are other issues which are harder to tackle:
> 1. profiling shows that Xpp3DomBuilder is called a lot of times. Since it is called with a Reader/InputStream I can't easily implement a cache here. 
> 2. jar files are always created and always installed. unlike the above actions, where the files were in the buffer cache, here actual IO occurs. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira