Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.0.8
-
None
-
None
Description
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.