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:19:45 GMT
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


Mime
View raw message