I've been running a few tests to measure performances. This simplistic test looks like running the following command in a loop and measure the execution time. This is done on a quite big project so that a bunch of pom files are actually read.
for i in 1 2 3 4 5 6 7 8 9 10 ; do time $MAVEN_HOME/bin/mvn -DskipTests -Dmaven.experimental.buildconsumer=true help:evaluate -Dexpression=java.io.tmpdir -DforceStdout -q ; done The average results are the following: Maven 4 with build/consumer: 28,40s Maven 4 w/out build/consumer: 23,43s Maven 3: 21,54s I find the 20% performance loss of the build/consumer feature quite problematic. I hinted about those possible performance problems when reviewing the original PR, so I'd like to see if I can investigate a different way of achieving the transformation. I think the main performance cost comes from using the following pattern: read file -> parse using JAXP -> transform using TRAX -> write to stream read stream -> parse using XPP3 The first step is performed in a separate thread and the output written to a pipe stream which is used as the input of the usual pom parser. This double parsing step, in addition to using the JAXP / TRAX api, which is not the fastest one, comes at a heavy cost. I see two ways to solve the problem: * refactor the build/consumer feature to use a different API so that the parsing can be done in a single step (this would mean defining an XmlFilter interface to do the filtering and wrapping it inside an XmlPullParser) * get rid of the Xpp3 implementation and use the more common Stax api which already defines filters The second option has some drawbacks though: all the plugin configuration done using Xpp3Dom would not work anymore, so this is a very big and incompatible change. I'm thus willing to investigate the first option and see what can be done. If there's a consensus, I'll start working on a POC about the api / filters and will get back to this list with some more information. -- ------------------------ Guillaume Nodet
