Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 83646 invoked from network); 5 Aug 2010 14:14:13 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 5 Aug 2010 14:14:13 -0000 Received: (qmail 11068 invoked by uid 500); 5 Aug 2010 14:14:12 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 10805 invoked by uid 500); 5 Aug 2010 14:14:10 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 10796 invoked by uid 99); 5 Aug 2010 14:14:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Aug 2010 14:14:09 +0000 X-ASF-Spam-Status: No, hits=-1.6 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_MED,SPF_NEUTRAL,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: 194.196.100.166 is neither permitted nor denied by domain of mark.hindess@googlemail.com) Received: from [194.196.100.166] (HELO mtagate6.uk.ibm.com) (194.196.100.166) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Aug 2010 14:14:00 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate6.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o75EDduw030694 for ; Thu, 5 Aug 2010 14:13:39 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o75EDd0s905360 for ; Thu, 5 Aug 2010 15:13:39 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o75EDd5N010280 for ; Thu, 5 Aug 2010 15:13:39 +0100 Received: from anaheim.local (dhcp-9-20-183-74.hursley.ibm.com [9.20.183.74]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id o75EDcPZ010274 for ; Thu, 5 Aug 2010 15:13:38 +0100 Message-Id: <201008051413.o75EDcPZ010274@d06av01.portsmouth.uk.ibm.com> X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-18) with nmh-1.3 In-reply-to: <201008041456.o74EuNhO004999@d12av03.megacenter.de.ibm.com> References: <4C56E4F8.2040105@googlemail.com> <8652591182674059221@unknownmsgid> <201008041456.o74EuNhO004999@d12av03.megacenter.de.ibm.com> Comments: In-reply-to Mark Hindess message dated "Wed, 04 Aug 2010 15:56:23 +0100." From: Mark Hindess To: dev@harmony.apache.org Subject: Re: [classlib][luni] Collections classes - code reviews and optimisations Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Aug 2010 15:13:38 +0100 In message <201008041456.o74EuNhO004999@d12av03.megacenter.de.ibm.com>, Mark Hindess writes: > > I've now refactored the exception code to the start of the methods and > shuffled some of the if else cases around a little. > > Next I plan to look at: > > 1) remove the following from addAll(...): > > if (this == collection) { > collection = (ArrayList)clone(); > } > > since it is immediately followed by a call to collection.toArray() so > it should be unnecessary. Done in r982377. I also checked in the review comments we made to make it easier to track them. > 2) Change the fields to firstIndex and size. I've now done this and checked it in at r982498. I also made a minor change (below) to ensureCapacity that Oliver observed does (accidentally) fix a bug that caused us to call a grow method with 0 growSize and do a pointless array copy shuffling the entire list. public void ensureCapacity(int minimumCapacity) { - if (array.length < minimumCapacity) { + int required = minimumCapacity - array.length; + if (required > 0) { // REVIEW: Why do we check the firstIndex first? Growing // the end makes more sense if (firstIndex > 0) { - growAtFront(minimumCapacity - array.length); + growAtFront(required); } else { - growAtEnd(minimumCapacity - array.length); + growAtEnd(required); } } } My initial (dacapo) benchmark runs on the original ArrayList, the version with exception refactoring, the version without the spurious clone and the version with the size changes seem to show that the exception handling change was a bad idea but that we get back the lost performance with the size change. I'm just re-running the benchmarks on a quiet(er) machine to confirm. Will post details when they've finished. Regards, Mark.