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 02:58:54 GMT
I recommended #1 a couple weeks back, and also asked if any of this
could be caused by StringBuffer's synchronization? I didn't get any
reply. My theory was that if alot of String ops we're going on, you
might want to figure out how to cut those out... even figure out how
to end up using StringBuilder on a 1.5+ JDK

On Wed, Aug 20, 2008 at 9:26 PM, Brian E. Fox <brianf@reply.infinity.nu> wrote:
> Honestly I half feel like flushing the fixes for all of this to 2.1 and
> leaving it as is in 2.0.x.
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Wednesday, August 20, 2008 10:06 PM
> To: dev@maven.apache.org
> Subject: Re: 2.0.10 performance.....
>
>
> Well, ideally to me, we'd just pursue option #2 and push that through.
> The
> problem is that doing so would delay 2.0.10 even further as that would
> require another plugin-tools release (which was just released today),
> etc....
>
> Thus, the question is, what to do to get 2.0.10 out?   The command line
> thing
> is one option.   The other thing I thought about is to somehow burn in
> the
> few plugins that this affects (clover, cobertura, maybe others) that we
> know
> about.
>
> We possibly could add something into the <configuration> things to
> signal it
> or a <special.plugins>clover,cobertura</..> property that we look for or
>
> similar, but that still would require modifying the poms which kind of
> violates your "just run mvn install" thing.   Maybe burn in the ones we
> know
> and allow the pom mod for those we don't know.
>
>
> Honestly, if it was completely my call, I would say pursue option #2 and
>
> release it as 2.1, not 2.0.10.
>
> Dan
>
>
> On Wednesday 20 August 2008 9:37:04 pm Brian E. Fox wrote:
>> I like both of those ideas.
>> My concern since we saw the performance issues was that it was
> affecting
>> everyone to fix just a few cases. If it could be off by default it
> would
>> be better, but setting a cli flag for this isn't a great use
> case...then
>> there's no way to specify it for people who wouldn't know better. This
>> is against the "I can just run mvn install on any maven project and it
>> works" philosophy.
>>
>> John, in absence of an annotation, is there any way to signal from the
>> pom that this is needed (ideally per plugin execution even)
>>
>>
>>
>> -----Original Message-----
>> From: Daniel Kulp [mailto:dkulp@apache.org]
>> Sent: Wednesday, August 20, 2008 9:07 PM
>> To: Maven Developers List
>> Subject: 2.0.10 performance.....
>>
>>
>> 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.
>>

Paul

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


Mime
View raw message