commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [MATH] Interest in large patches for small cleanup / performance changes?
Date Sat, 02 Nov 2013 16:49:27 GMT
On 11/2/13 8:19 AM, Sean Owen wrote:
> 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.

If the improvements make a material difference [1], by all means
open tickets and submit patches.  If they are just cosmetic, my
personal opinion is this should be done in small commits
incrementally if at all [2].  It is OK to open master tickets to
track style / optimization changes and do the work to review and
commit them incrementally.  The master ticket should be preceded by
discussion here to make sure we are all in agreement that the
changes are appropriate.

You mention quite a few different kinds of thing above.  It is
probably best to break up into different discussion threads by
topical area and then open master tickets for the ones we agree to
fix / standardize.  Regarding the javadoc errors (broken javadoc
references, missing / incorrect @deprecates), there is no need for
discussion - just open tickets and we can commit the fixes.

Phil

[1] I know what "material difference" means is inherently
subjective.  For me it means either material performance improvement
or significantly improved readability / approachability.  I have
consistently argued against too many "style rules" because they
create barriers to entry for those trying to comply with them. 
Think about all of the examples you mention above in terms of new
contributors, some of whom may be top notch applied mathematicians
coming from a primarily C or other-language background.  Why burden
them (or us - which will include you soon enough - hehe) with the
tedious work to make their code comply with every Java coding best
practice we can imagine - *unless it makes a real difference to
performance or readability*?

[2] See "Value laziness as a virtue" and "Small, reversible steps"
starting about slide 167 in
http://www.betaversion.org/~stefano/papers/ac2006.2.pdf
>
> 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
>
>


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


Mime
View raw message