[
http://jira.codehaus.org/browse/MNG-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3647:
------------------------------
Fix Version/s: 2.0.x
it might be best to break this into specifically addressable issues
> Maven performance needs improvement
> -----------------------------------
>
> Key: MNG-3647
> URL: http://jira.codehaus.org/browse/MNG-3647
> Project: Maven 2
> Issue Type: Bug
> Affects Versions: 2.0.8
> Reporter: Ittay Dror
> Fix For: 2.0.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
