So, I've been working on the hotspots (late last night and again this
morning) trying to see what improvements I could make. In the end, I was
able to improve things a bit in terms of interpolation efficiency and
model cloning (turned out that was a big time sink too). However, in the
end I think the sheer number of transitions between concrete and dynamic
state are just crushing the life out of this.
I talked briefly with you, Dan, yesterday about detecting whether some
key parts of the project/model graph had changed, and using those to
trigger a concrete -> dynamic transition...otherwise, leaving the
project in concrete mode until such a trigger trips. Thinking about this
more, I think we could easily cover 90% of use cases with this approach,
right off the bat. From that point, we could probably hone the detection
system over time to pick up on anything we missed. I think this has a
lot of potential to improve the performance numbers, and it's something
I've just started to pursue here.
I'm not wild about adding the new annotation for now, simply because of
the time and pain involved in bringing all of the affected plugins up to
snuff (they'd have to have new releases as well). As for detecting
project-state changes in the plugin itself (or the POM, as Brian asked
about) we'd have to scan the entire logic of the mojo (and classes it
used) to see whether any of it modified the project/model graph...which
is obviously waaaay too heavy to do at runtime.
Additionally, as for adding a command-line option: this would definitely
work, but it would be putting the onus on the user to adapt to our
deficient design. It would inevitably increase the confusion around the
use of Maven ("When do I use the dynamic flag, when can I skip it...why
should I care?") and in any case I'm concerned about building up more
legacy to support in things like that, once we find a real solution to
the problem.
For now, I'm going to look more closely into these trigger values.
Please let me know if you have any ideas...
Thanks,
-john
Daniel Kulp wrote:
The latest stuff on John's branch is "better", but it's still about 4x - 5x
slower for some of the actions I do several times a day. I'd estimate that
I'd end up wasting 20-30 minutes a day waiting for it compared to 2.0.9. I
find that unacceptable and wouldn't be able to recommend it get rolled out to
other developers. I couldn't "cost justify" reducing the productivity of
everyone.
However, the dynamic re-interpretation stuff is needed due to a few plugins
doing some strange things. (clover, cobertura, etc...) The problem is that
it causes a major slowdown for ALL plugins, even the "well behaved" plugins.
My suggestion would be:
1) Leave the reinterpret code in, but turn it off by default. Add a command
line flag or system property to turn it on in the cases that it's needed.
The default behavior would be no worse than 2.0.9.
2) Extend the plugin model to add a "@modifiesBuildEnvironment" or something
similar so a plugin can let the execution environment know that special care
will need to be taken after this plugin runs. Once that is in place, future
versions of the affected plugins could set that to make sure things work
correctly.
Thoughts?
--
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]
