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.
>
> 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
