No, I don't think this requires a delay in the alpha-1 release. Le jeu. 1 juil. 2021 à 12:27, Robert Scholte <rfscho...@apache.org> a écrit :
> Should we postpone the alpha-1 release because of this? > For me the most important reason for alpha-1 is to get confirmation that > builds won't be broken due to build/consumer. > But if users simply look at buildtime and due to some slower result don't > care for the other changes, then we shouldn't do this release now. > > Robert > > > > On 1-7-2021 11:20:17, Guillaume Nodet <gno...@apache.org> wrote: > 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
