I've raised a PR for review https://github.com/apache/maven/pull/486/ This kina rewrites the build/consumer transformation to reuse the xml pull parser and do the transformation on the fly instead of reading and transforming with a sax api and writing to a stream so that the pull parser can read it again. At first glance, it seems to get the build/consumer feature with performances much closer to the performances when the feature is disabled:
Maven 4 with build/consumer: 23,12s Maven 4 w/out build/consumer: 22,43s I'll investigate the failure on windows tomorrow, but I suspect a line ending problem... I'll also raise a JIRA to track this improvement. I've done some measurements with the sync factory, but that did not seem to change much for this use case. Guillaume Le jeu. 1 juil. 2021 à 11:19, Guillaume Nodet <gno...@apache.org> a écrit : > 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 > > -- ------------------------ Guillaume Nodet
