commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <sro...@gmail.com>
Subject Re: [MATH] Interest in large patches for small cleanup / performance changes?
Date Sat, 02 Nov 2013 15:19:05 GMT
There are tens of possible types of changes here, each affecting tens
or even 100+ files. I wondered if it would be irritating to open,
potentially, tens of JIRAs.

Maybe I can start with a JIRA or two, each addressing one or a few
closely-related changes. If it's going well, I can propose more until
it's clear we're getting too fine-grained.

I'll do this over time since some changes will affect the same files
or sections of code.

On Sat, Nov 2, 2013 at 3:03 PM, Gilles <gilles@harfang.homelinux.org> wrote:
> On Sat, 2 Nov 2013 14:52:34 +0000, Sean Owen wrote:
>>
>> In Math, is there any appetite for large patches containing many
>> instances of particular micro-optimizations? Examples:
>>
>> - Replace:
>>     a[i][j] = a[i][j] + foo;
>>   with:
>>     a[i][j] += foo;
>>   … which is faster/leaner in the byte code by a little bit. It might
>> make a difference in many nested, tight loops.
>> - Inefficient toArray() calls with 0-length arg
>> - Using Map.entrySet() instead of keySet() + get()s
>> - Unnecessarily non-static private methods/classes
>> - StringBuffer vs StringBuilder
>> - etc.
>>
>> There are some non-functional but still possibly useful, simplifying
>> changes too:
>>
>> - Add @Deprecated annotations
>> - Fix broken method refs in javadoc
>> - Removing unnecessary boxing/unboxing
>> - Using foreach where possible
>> - etc.
>>
>> I could go on for a while. Most of what I might otherwise suggest is
>> style-level stuff like fixing C-style array declarations which is
>> unlikely to be useful enough to justify. Or, it would involve changing
>> signatures somewhere, which is probably not cool.
>>
>> If there’s interest in these sorts of things I can generate one or
>> more patches easily. The downside is the disruption of large patches,
>> perhaps breaking existing patches.
>
>
> I think that is good to have a uniform style.
> But why would a big patch be unavoidable? Reviewing a few changes is easier.
>
> Thanks for your help with this,
> Gilles
>
>
> [1] If just for better readability. But not the majority shares this view
>     around here.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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


Mime
View raw message