I got the speed issue reduced to where it's adding something less than a
minute on the site build for maven (that's including clean; since we
can't reliably tell which plugins are smart enough to avoid
re-execution, I considered it simpler to start clean each time). I was
able to do this by writing a new ModelInterpolator that uses
String.indexOf(..) instead of a regex Pattern/Matcher to search for
expressions. The code is very similar, and has been tested pretty
thoroughly...and best of all, it results in a pretty big performance gain.
However, the problem I'm looking at now is the memory consumption.
Running a "normal" build, it uses about the same memory as 2.0.9.
Running a site build where there are a couple of pseudo-aggregators
bound to the lifecycle - resulting in many, many forked trips through
the same project set and basic build - the memory usage is quite a bit
higher. For instance, running `mvn -Prelease,reporting clean site`
resulted in something like 110M of memory being in use when the build
finished.
It seems like most of the memory consumption is coming from plexus,
mainly from Xpp3Dom and associated classes. I'm not sure how far into
the plexus stuff we want to dig for 2.0.10, but I'll keep looking for
now. We may also want to think about making the next release (2.1.1 if
2.0.10 -> 2.1, or whatever) simply a performance upgrade, to rebase
development going forward. If we have the flexibility of moving to JDK
1.5 as a minimum requirement, then we can explore replacing StringBuffer
with StringBuilder, and maybe get the Xpp3Dom stuff cleaned up somehow.
IMO we should be able to find some way of preserving the Xpp3Dom API
while replacing the guts with something cleaner, so we could preserve
compat for plugins using the plugin-configuration sections of the POM, etc.
If anyone has insight/ideas they'd like to share about this stuff, I'm
all ears.
Thanks,
-john
Daniel Kulp wrote:
When I'm running my test, it's not from a clean directory. Everything is
already built. Thus, for the most part, the build doesn't really do
anything. You basically end up configuring a bunch of plugins that see that
they don't have to do anything. Thus, it's perfect for timing how much time
MAVEN is doing things, and not javac or resources or checkstyle or anything.
That's the number I care about. If an automated build from clean source
takes an extra 20%, I don't really care. However, if normal developer
builds that aren't building from completely clean trees take 800% longer,
that's a HUGE problem.
How long would
mvn -Prelease,reports install site -Dmaven.test.skip.exec=true
if run twice?
Dan
On Tuesday 19 August 2008 11:42:53 am John Casey wrote:
I'm trying to run the CXF build on Hudson right now with a RC10
snapshot, so hopefully I can find out why your times are so far off in
CXF...
I adjusted a few things last night to try to streamline the
concretization for aggregators and users of reactor projects. When I was
done, the full build for maven's core (mvn -Prelease,reports clean
install site) only took 2 minutes longer than the 13-minute 2.0.9 build...
I'm wondering what circumstances are present in the CXF build that throw
that one so wide of where 2.0.9 lands.
-john
Daniel Kulp wrote:
Just another quick note...
Our -Pfastinstall profile (to build/install as fast as possible)
2.0.9:
[INFO] Total time: 32 seconds
[INFO] Finished at: Mon Aug 18 21:51:07 EDT 2008
[INFO] Final Memory: 53M/94M
2.0.10-RC9:
[INFO] Total time: 4 minutes 39 seconds
[INFO] Finished at: Mon Aug 18 21:56:04 EDT 2008
[INFO] Final Memory: 77M/145M
I was just going to mention the memory thing as well. However, my
MAVEN_OPTS are set at:
MAVEN_OPTS=-XX:MaxPermSize=192m -Xmx512M
so it definitely had plenty of memory to play with.
This is cxf trunk:
http://svn.apache.org/repos/asf/cxf/trunk/
mvn -Pfastinstall
Dan
On Monday 18 August 2008 9:05:35 pm Daniel Kulp wrote:
John,
The performance issue is back:
For CXF/tunk:
mvn install -Pdeploy,everything,nochecks
2.0.9:
Total time: 8 minutes 35 seconds
2.0.10-RC9:
Total time: 19 minutes
Dan
On Monday 18 August 2008 2:48:36 pm John Casey wrote:
Hi everyone,
As you're probably aware, we've been working for some time to stabilize
Maven for the 2.0.10 release. After quite a bit of testing in the
development community - and 8 release candidates - it looks like we
finally have a candidate that is free of regressions and stable. You
can download it here:
http://people.apache.org/~jdcasey/apache-maven/2.0.10-RC9/org/apache/ma
ve n/ apache-maven/2.0.10-RC9
While it does seem that all of our builds are happy with the new
release candidate, we'd like to get your feedback on it before we
finalize things. This will help us respond to any regressions or
critical issues we may have missed BEFORE we do the release, instead of
having to put up with major flaws for another release cycle.
Please, if you have the time, take 2.0.10-RC9 for a spin and tell us
what you think!
Thanks,
-john
P.S. To see the list of issues that were closed for this release (so
far), check out:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleN
am e= Html&version=14112
--
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]
