John,
Just a quick note before I head off to bed....
With the latest code on the 2.0.10-RC branch, my CXF test is now down to 44
seconds. (2.0.9 is about 33 secs) Memory usage is about the same:
2.0.9: 53M/94M
2.0.10-RC: 55M/100M
This is "mvn -Pfastinstall" from a non-clean build. Basically, run it once
to make sure everything is built, then run a second time for the real time.
Anyway, you're getting there. Huge improvement since yesterday. :-)
Dan
On Thursday 21 August 2008 12:24:46 pm John Casey wrote:
> 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?
--
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
