You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2016/06/17 19:50:54 UTC
NameAbbreviator.MaxElementAbbreviator.getMinCount(Strategy)
Should this:
private int getMinCount(final Strategy strategy) {
if (Strategy.DROP == strategy) {
return 0;
} else { // Strategy.RETAIN
return 1;
}
}
be:
private int getMinCount(final Strategy strategy) {
return strategy.getMinCount();
}
?
Seems more OO to me.
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: NameAbbreviator.MaxElementAbbreviator.getMinCount(Strategy)
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Jun 17, 2016 at 4:25 PM, Remko Popma <re...@gmail.com> wrote:
> Yes, your suggestion is better.
> Not only cleaner, but also more performant: in the first case the cpu will
> speculatively execute both branches. One of them will fail and that
> execution pipeline will be discarded. Not a big deal, happens all the time,
> and branch prediction is very good these days, but if the conditional can
> be avoided, the cpu can continue to make progress. If you can choose,
> prefer math to branching code.
>
Done. In Git master.
Gary
>
> Sent from my iPhone
>
> On 2016/06/18, at 4:50, Gary Gregory <ga...@gmail.com> wrote:
>
> Should this:
>
> private int getMinCount(final Strategy strategy) {
> if (Strategy.DROP == strategy) {
> return 0;
> } else { // Strategy.RETAIN
> return 1;
> }
> }
>
> be:
>
> private int getMinCount(final Strategy strategy) {
> return strategy.getMinCount();
> }
>
> ?
>
> Seems more OO to me.
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: NameAbbreviator.MaxElementAbbreviator.getMinCount(Strategy)
Posted by Remko Popma <re...@gmail.com>.
Yes, your suggestion is better.
Not only cleaner, but also more performant: in the first case the cpu will speculatively execute both branches. One of them will fail and that execution pipeline will be discarded. Not a big deal, happens all the time, and branch prediction is very good these days, but if the conditional can be avoided, the cpu can continue to make progress. If you can choose, prefer math to branching code.
Sent from my iPhone
> On 2016/06/18, at 4:50, Gary Gregory <ga...@gmail.com> wrote:
>
> Should this:
>
> private int getMinCount(final Strategy strategy) {
> if (Strategy.DROP == strategy) {
> return 0;
> } else { // Strategy.RETAIN
> return 1;
> }
> }
>
> be:
>
> private int getMinCount(final Strategy strategy) {
> return strategy.getMinCount();
> }
>
> ?
>
> Seems more OO to me.
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory