maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Benedict" <pbened...@apache.org>
Subject Re: 2.0.10 performance.....
Date Thu, 21 Aug 2008 22:20:40 GMT
Well, before anyone begins doing 2.1 work, take the 3.0.x tickets and
update the descriptions of them. Many 3.0 tickets still descibe "2.1"
in their title.

Paul

On Thu, Aug 21, 2008 at 5:19 PM, Ralph Goers <Ralph.Goers@dslextreme.com> wrote:
> Where does all this leave 2.0.10? Shouldn't that be the first thing out?
>
> John Casey wrote:
>>
>> No, it means it doesn't have all of the things causing the performance
>> problems (I did merge some stuff in several times around-and-before RC6 or
>> later), and none of the performance fixes I'm working on now.
>>
>> IMO we should look at the current 2.1.x branch as working toward a 2.1.1
>> release, and reconfigure things such that 2.0.10-RC branch is in fact
>> working toward a 2.1.0 release.
>>
>> Ralph Goers wrote:
>>>
>>> Brett created the 2.1.x branch on Aug 12. I believe it was from whatever
>>> was currently in the 2.0.x branch at the time.  The work I am doing is
>>> against that branch but I haven't committed anything yet. I still have quite
>>> a bit of testing to do.  I would prefer to just have whatever is in
>>> 2.0.10-RC merged to 2.1.x. I can't imagine it would be that big of a deal.
>>>
>>> If I am understanding correctly, does this mean the 2.0.x branch does not
>>> have the changes that are causing the performance problems?
>>>
>>>
>>> Brian E. Fox wrote:
>>>>
>>>> I agree. We'd have to figure out how to merge Dan's reactor changes in
>>>> as I'm not sure where the 2.1 branch came from that he used. I would
>>>> probably rename the current 2.0.10 branch to 2.1.x, then merge the
>>>> branch dan used into it. We could then port the real bug fixes from the
>>>> current 2.0.10 back to the 2.0.x branch and do a new 2.0.10. Confused
>>>> yet?
>>>>
>>>> -----Original Message-----
>>>> From: John Casey [mailto:jdcasey@commonjava.org] Sent: Thursday, August
>>>> 21, 2008 1:32 PM
>>>> To: Maven Developers List
>>>> Subject: Re: 2.0.10 performance.....
>>>>
>>>> I'd say the 2.0.10 release ought to become 2.1.0. I think most of us are
>>>>
>>>> thinking similar things at this point (based on conversations I've seen
>>>> here and on IRC), and its implementation is certainly different enough to
>>>> warrant it.
>>>>
>>>> Ralph Goers wrote:
>>>>
>>>>>
>>>>> I'm still wondering if given the impact this has shouldn't it be
>>>>>
>>>>
>>>> pulled
>>>>>
>>>>> from 2.0.x and moved into 2.1?  In my view the purpose of 2.1.x is it
>>>>> lock down 2.0.x to bug fixes that don't introduce new behaviors.
>>>>> 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?
>>>>>>>
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message