2015-01-26 14:05 GMT+01:00 Gary Gregory <garydgreg...@gmail.com>:
> On Mon, Jan 26, 2015 at 7:03 AM, Benedikt Ritter <brit...@apache.org>
> wrote:
>
> > Hello Adrian
> >
> > 2015-01-24 19:43 GMT+01:00 Adrian Crum <
> adrian.c...@sandglass-software.com
> > >:
> >
> > > Slightly off-topic but somewhat related...
> > >
> > > I saw a recent commit where a "performance improvement" went something
> > > like this:
> > >
> > > StringBuilder sb = new StringBuilder();
> > > sb.append("foo");
> > >
> > > was replaced with
> > >
> > > StringBuilder sb = new StringBuilder("foo");
> > >
> > > The change reduced the code by one line, but there was no "performance
> > > improvement" - because the StringBuilder constructor calls append().
> > >
> >
> > All methods on StringBuffer are synchronized, so there a slight overhead
> of
> > acquiring the lock. This is usually the argument for using StringBuilder
> > over StringBuffer.
> >
>
> Woa, going from builder to buffer sounds wrong unless synchronization is
> required.
>
D'oh, meant it the other way around ;-) sorry for the confusion!
>
> Gary
>
> >
> >
> > >
> > > So, I agree that suggested performance improvements should be met with
> a
> > > great deal of skepticism and they should be closely scrutinized.
> > >
> > > Adrian Crum
> > > Sandglass Software
> > > www.sandglass-software.com
> > >
> > >
> > > On 1/24/2015 10:21 AM, Thomas Neidhart wrote:
> > >
> > >> Hi,
> > >>
> > >> from time to time some researchers trying to find performance bugs in
> > >> open-source software create issues for collections.
> > >>
> > >> One of the easy targets is the Collection#retainAll(Collection) method
> > >> as the default implementation in AbstractCollection calls contains on
> > >> the provided collection.
> > >>
> > >> Now, in the worst-case this may lead to a runtime complexity of
> O(n^2),
> > >> i.e. when the collection has a contains implementation with O(n)
> > >> complexity.
> > >>
> > >> The proposed solution is usually to create an intermediate set and use
> > >> it to speed up the contains calls.
> > >>
> > >> My position was always that a given Collection class shall not
> overwrite
> > >> this method trying to optimize its runtime behavior for any possible
> > >> input by creating such intermediate data structures as this will just
> > >> increase the space complexity (in many cases unnecessarily). Instead,
> > >> the runtime complexity was documented (one can even question this as
> the
> > >> Collection framework should be well-known by java users).
> > >>
> > >> It looks like that at 2 occasions these "performance bugs" got fixed:
> > >>
> > >> * https://issues.apache.org/jira/browse/COLLECTIONS-426
> > >> * https://issues.apache.org/jira/browse/COLLECTIONS-427
> > >>
> > >> and I would like to revert these fixes as they are wrong imho and just
> > >> create a precedent for further tickets.
> > >>
> > >> Does anybody challenge my rationale behind this or can I go ahead with
> > it?
> > >>
> > >> Thomas
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>
> > >>
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@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
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
