Here are some results for our project, running clean install -DskipTests: 2.0.9: 2 minutes 26 seconds 2.0.10-RC3: 2 minutes 42 seconds 2.0.10-RC5: 3 minutes 7 seconds
Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode) Asgeir On Mon, Aug 4, 2008 at 21:42, Brian E. Fox <[EMAIL PROTECTED]> wrote: > Ok if it's a modest change then that's ok. I was scared by that 3x change but > since we aren't seeing that elsewhere, then lets go forward with the RC and > see if anyone else has issues. > > -----Original Message----- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: Monday, August 04, 2008 12:49 PM > To: Maven Developers List > Subject: Re: Maven 2.0.10-RC5 > > I've checked the maven core and plugins builds, and they're both running > around 30s longer than with 2.0.9, with slightly less memory > consumption. Other builds I've tried are running nearer to +15s over 2.0.9. > > Granted, these aren't huge builds, but neither are they the 3X time > increase over 2.0.9 that others are reporting. Can we live with this > performance issue through 2.0.10, and try to find a better way around > for 2.0.11? > > I know that forked plugins is a slightly marginal priority, but I'm > willing to bet that more people are using checkstyle than are > experiencing huge build-time increases. Rolling back the change that led > to this performance degradation will either reinstate a regression > caused in the 2.0.9 release, or - if we attempt to also fix that - > reinstate some very buggy behavior WRT build paths during interpolation > that has existed in one form or another since 2.0. > > IMO we have a couple problems here that are largely design issues: > > - project/build state can be changed without limit by plugins > > - plugins in forked lifecycles depend on changes from previous plugins > being propagated into those forked lifecycles > > - build paths are impossible to trace through the interpolation process, > so adjusting these interpolation points with new build paths is equally > impossible. Even adjusting them to be absolute build paths as opposed to > relative ones has proven a very difficult task in the past (this was > fixed in 2.0.9, which triggered all of this). > > John Casey wrote: >> If we had more options WRT parsing POM fragments using the generated >> modello code, it might be possible to do on-demand interpolation during >> expression evaluation for plugin instance configuration...though I'm not >> sure how much that would help. >> >> BTW, I don't know for a fact this is the hot spot causing a 3X >> performance hit, but it's pretty intensive so I'd say it's a very good >> educated guess. >> >> -john >> >> John Casey wrote: >>> The problem is, this was a regression issue, based on real >>> improvements we made to the interpolation code in 2.0.9. >>> >>> To boot these issues to 2.1, we'd need to find a way to reintroduce >>> buggy handling of build paths into the interpolator. >>> >>> >>> >>> Brian E. Fox wrote: >>>> I agree it should be right, but a 3x hit in build times isn't >>>> acceptable. Given the alternative, I would probably boot those issues >>>> to 2.1 where they can be handled correctly. The majority of users >>>> probably aren't getting hit by these bugs, so forcing the performance >>>> hit on them will appear as a regression, not an improvement. >>>> >>>> -----Original Message----- >>>> From: John Casey [mailto:[EMAIL PROTECTED] Sent: Monday, August >>>> 04, 2008 10:18 AM >>>> To: Maven Developers List >>>> Subject: Re: Maven 2.0.10-RC5 >>>> >>>> Brett, >>>> >>>> This change was in place long before the javadoc plugin problem of >>>> the last RC. The problem happens when forking at times, too, since >>>> those forked lifecycles sometimes require alternative target >>>> directory, etc. If that information has already been interpolated, >>>> changeing target directory and associated paths gets problematic >>>> quickly. >>>> >>>> The fact that any plugin can change project state at will means that >>>> we have to be able to propagate these changes to the next plugin. >>>> Dirty flags aren't enough here, since it could be literally anywhere >>>> in the Model object hierarchy, in the various collections housed in >>>> the project instance, etc. >>>> >>>> I'm happy to take a less invasive approach here, *if* we can find a >>>> way to make behavior consistent. IMO consistency is much more >>>> important than speed. In a perfect world, we'd control the mutability >>>> of project and build state more carefully, or even retain a more >>>> efficient data tree that we could use to incorporate changes and >>>> update build paths, plugin configs, etc. more quickly. The approach I >>>> added was geared to fit within the constraints of the current data >>>> model. >>>> >>>> -john >>>> >>>> Brett Porter wrote: >>>>> Hey John, >>>>> >>>>> Is it necessary for the project on every execution? I thought this >>>>> was just for ${reactorProjects} - which could be handled on demand >>>>> in the PPEE? >>>>> >>>>> It might be worth running the profiler over it too to see if there >>>>> are any particular hotspots that could improved regardless. >>>>> >>>>> - Brett >>>>> >>>>> On 04/08/2008, at 10:55 PM, John Casey wrote: >>>>> >>>>>> This may have to do with some very inefficient code I had to put in >>>>>> to solve MNG-3530. It's doing interpolation of the build section of >>>>>> the POM per-plugin now, and restoring it to the dynamic state just >>>>>> after each plugin executes. This was necessary to allow >>>>>> modifications to the project instance happening during a plugin's >>>>>> execution to be seen in successive plugins. >>>>>> >>>>>> The execution should be correct now, but unfortunately the design >>>>>> of the system prevented an efficient solution. If you would like to >>>>>> look over the code, it's in the >>>>>> MavenProject.calculateConcreteState(..), >>>>>> MavenProject.restoreDyanmicState(..), >>>>>> PluginManager.executeMojo(..), >>>>>> PluginParameterExpressionEvaluator.evaluate(..), and >>>>>> PluginManager.getReport(..) methods. >>>>>> >>>>>> I'd love suggestions. >>>>>> >>>>>> -john >>>>>> >>>>>> Jörg Schaible wrote: >>>>>>> Hi, >>>>>>> John Casey wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Here's your daily dose of Maven 2.0.10! I've fixed the regressions >>>>>>>> pointed out in RC4, and added integration tests to guard >>>>>>>> against their >>>>>>>> reintroduction. The new release candidate can be found here: >>>>>>>> >>>>>>>> http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC >>>>>>>> 5/org/apache/maven/apache-maven/2.0.10-RC5 >>>>>>>> >>>>>>>> The release notes (again): >>>>>>>> >>>>>>>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=105 >>>>>>>> 00&styleName=Html&version=14112 >>>>>>>> >>>>>>>> Please try it out and let me know if things go wrong. >>>>>>> Does someone else than me also notice a major performance >>>>>>> decrease? If I perform a build for our ~150 artifacts it takes >>>>>>> with M2010RC5 ~3h while the same task consumes about 40min with >>>>>>> M209. Similar results when generating the Eclipse projects. >>>>>>> - Jörg >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>> -- >>>>>> John Casey >>>>>> Developer, PMC Member - Apache Maven (http://maven.apache.org) >>>>>> Blog: http://www.ejlife.net/blogs/buildchimp/ >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>> >>>>> -- >>>>> Brett Porter >>>>> [EMAIL PROTECTED] >>>>> http://blogs.exist.com/bporter/ >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>> >>> >> > > -- > John Casey > Developer, PMC Member - Apache Maven (http://maven.apache.org) > Blog: http://www.ejlife.net/blogs/buildchimp/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
