I agree. We could even mention this known performance "issue" so there wouldn't be any surprise.
/Anders On Thu, Jul 1, 2021 at 12:29 PM Enrico Olivelli <eolive...@gmail.com> wrote: > Il giorno gio 1 lug 2021 alle ore 12:27 Robert Scholte < > rfscho...@apache.org> > ha scritto: > > > 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. > > > > 100% agreed > it is an ALPHA and there are many cool features, it is worth to give it to > the users and get feedback > > my two cents > Enrico > > > > 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 > > >
