[
http://jira.codehaus.org/browse/MNG-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141022#action_141022
]
Ittay Dror commented on MNG-3647:
---------------------------------
Note: I don't want this issue to become a discussion about a suggestion I made
in a comment and not the concrete improvements I wrote in the main description.
About the plugins. Think of a scenario where I write a pom.xml for a module
where I know there isn't any src/main/resources folder, and hence nothing for
the resources plugin to do. What I would want to be able to do is to write in
pom.xml something like:
....
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<disabled>true</disabled>
</plugin>
maven will then remove this plugin from the lifecycle, and with it the overhead
of initializing all objects and data just so the 'execute' doesn't do anything.
i fail to see how it goes against pluggability or out-of-the-box. if i do
nothing, the plugin runs (maybe print a warning that it has nothing to do and
suggest it will be disabled?)
> 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
