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
