maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: 2.0.10 performance.....
Date Thu, 21 Aug 2008 22:04:28 GMT
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


Mime
View raw message