I think it's something to put in the RC post, focus on testing:
- interpolation
- deployment and proxies
- any reproducible, consistent speed degradation
It would probably still be worth inspecting the performance with a
tool sucha s yourkit... Jörg is there any chance you could do that on
your build to see where you're getting hit?
- Brett
On 05/08/2008, at 5:42 AM, Brian E. Fox 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]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
