[
http://jira.codehaus.org/browse/MNG-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=140388#action_140388
]
Milos Kleint commented on MNG-3647:
-----------------------------------
read about maven lifecycle.
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
"mvn compile" will iterate phases up to the compile one and execute every mojo
bound to the given phases. it either executes the mojos correctly or your
project is wrongly setup.
> 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
>
> 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
