Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of ralph.goers@dslextreme.com
 designates 66.51.199.94 as permitted sender)
Message-ID: <48AE53FF.6090408@dslextreme.com>
Date: Thu, 21 Aug 2008 22:51:59 -0700
From: Ralph Goers <Ralph.Goers@dslextreme.com>
Reply-To: rgoers@apache.org
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Maven Developers List <dev@maven.apache.org>
Subject: Re: 2.0.10 performance.....
References: <200808202106.48160.dkulp@apache.org>
 <48AD96CE.9080004@commonjava.org> <48ADA1C6.4010501@dslextreme.com>
 <48ADA67A.10208@commonjava.org>
 <2BABBE7D2A66E04DB8A66A527D29927E404536@intrepid.infinity.nu>
 <48ADE55F.7040302@commonjava.org>
 <3FA719A6-9EC7-405C-908C-DD166663D5AD@apache.org>
 <48ADFC1D.5050209@dslextreme.com> <48AE09CF.50208@commonjava.org>
 <48AE2968.2020009@dslextreme.com> <48AE2EFA.5000001@commonjava.org>
In-Reply-To: <48AE2EFA.5000001@commonjava.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sure.  Just so you know I am running this on Ubuntu running in a VM 
under Windows on a Thinkpad T60. It has 3GB of memory of which I've 
given 1.5GB to Linux.  I do have a faster machine but I've been working 
on my stuff on the laptop.

I ran the builds all over again and got slightly different times. First 
after cleaning:

3:36 for 2.0.9
4:14 for 2.0.10-RC
8:47 for 2.1.x
8:28 for 2.1.x with my changes.


I ran the build without cleaning in between. I got
1:11 for 2.0.9
1:29 for 2.0.10-RC
6:06 for 2.1.x
6:01 for 2.1.x with my changes.

In addition, I've noticed that even mvn clean is much slower on the 2.1 
branch than on 2.0.9.
23 seconds for 2.0.9
21 seconds for 2.0.10-RC
1:03 for 2.1.x

You are clearly in the ballpark.

Ralph

John Casey wrote:
> Would you mind running with the latest code on the RC branch? I ran 
> it, but I'm not sure I have the environment setup the way people would 
> expect. The SVN for that branch is:
>
> https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.10-RC 
>
>
>
> Ralph Goers wrote:
>> Yeah, I don't think you need to be all that selective.  I agree that 
>> 2.1.0 needs all the work you've been doing. I just ran the cxf build 
>> on the 2.1.x branch. Here are the results I get when running mvn 
>> -Pfastinstall install:
>>
>> 4:49 for 2.0.9,
>> 8:51 on 2.1.x
>> 8:41 on 2.1.x with my changes.
>>
>> Memory usage was about the same on all of them. I'm not sure why it 
>> was a little faster with my changes. It probably isn't really any 
>> different. From what I can tell my changes shouldn't affect the cxf 
>> build.
>>
>> Ralph
>>
>> John Casey wrote:
>>> As far as selective merging to 2.1.x, of course we'll keep things 
>>> like Dan's change, but where does that leave all of the stabilizing 
>>> work on the RC branch? Most of the substantive changes in the RC 
>>> branch is also in the 2.1.x branch, so to me it makes more sense to 
>>> sync 2.1.x up with the RC branch (the 2.1.x branch should accept all 
>>> of the RC branch changes, and incorporate the new code such as Dan's 
>>> and Ralph's work). I guess I'm not sure how to interpret the 
>>> 'selective' part of option 1.
>>>
>>> Then, we can roll back the 2.0.x branch and decide how to move 
>>> forward there to fix the worst problems with 2.0.9. The extent of 
>>> changes in the RC branch make it a little risky to say the least for 
>>> a 2.0.10 release. It's not that it's functionally that different 
>>> from the other 2.0.x releases, but the implementations have changed 
>>> significantly.
>>>
>>> At any rate, we've put in an awful lot of work on this RC branch to 
>>> simply discard the stability we've achieved and resume work toward 
>>> some as-yet-undetermined release date.
>>>
>>> I have a strong preference to get the code in the RC branch released 
>>> under *some* version very soon now, then regroup to incorporate any 
>>> changes from Dan or Ralph that might destabilize things again. There 
>>> are important fixes in this code, and one of the big advantages of 
>>> pushing trunk to 3.0.x was to allow a release of intermediate code 
>>> in the near future...let's not throw that away.
>>>
>>> Ralph Goers wrote:
>>>> My non-binding preference is for option 1. I'm not crazy about 
>>>> renaming 2.0.10-RC.  I'd really be surprised if merging that to 
>>>> 2.1.x would be all that hard.
>>>>
>>>> Brett Porter wrote:
>>>>> This doesn't particularly appeal to me. maven-2.0.x is stranded in 
>>>>> a half merged state.
>>>>>
>>>>> The current 2.1.x was cut from 2.0.x and I figured we'd just merge 
>>>>> everything that hit maven-2.0.x.
>>>>>
>>>>> I'd prefer one of
>>>>> 1) merge all your stuff selectively to 2.1.x (along with Dan's 
>>>>> changes), and roll 2.0.x back (but keep other bug fixes we can 
>>>>> release as 2.0.10)
>>>>> 2) carry on the 2.0.10 approach
>>>>>
>>>>> It seems like 2 is becoming less feasible though due to the extent 
>>>>> of changes it has needed for an RC branch?
>>>>>
>>>>> Maybe not completely thought through - I'm rushing out the door 
>>>>> for a long weekend :) Will respond to your other mails Monday.
>>>>>
>>>>> Cheers,
>>>>> Brett
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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