Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of mreutegg@day.com designates
 207.126.148.182 as permitted sender)
MIME-Version: 1.0
Sender: mreutegg@day.com
In-Reply-To: <4A2847D3.2080103@trivantisdev.com>
References: <4A2847D3.2080103@trivantisdev.com>
Date: Mon, 8 Jun 2009 10:33:03 +0200
Message-ID: <a781e7950906080133t7665d5bar27b506b48db1714d@mail.gmail.com>
Subject: Re: Performance Improvement Code Fix to AbstractRecord
From: Marcel Reutegger <marcel.reutegger@gmx.net>
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

this has already been reported and fixed. See:
https://issues.apache.org/jira/browse/JCR-1988

regards
 marcel

On Fri, Jun 5, 2009 at 00:16, Eric <thomas@trivantisdev.com> wrote:
> We were having performance issues during the commit of a transaction that
> contained a huge amount of node inserts. =A0We found that a big chunk of =
the
> commit time was spent in the method
> org.apache.jackrabbit.core.journal.AbstractRecord.getOrCreateIndex(). =A0=
In
> this class, the uuidIndex instance variable is an ArrayList and
> uuidIndex.indexOf(nodeId) is called to search through this ArrayList to s=
ee
> if a node is already in the list. =A0ArrayList.indexOf() searches the lis=
t
> from beginning to end calling NodeId.equals() until the entry is located =
and
> then returns. =A0This can be quite inefficient if the list becomes large.
>
> In our case, we had *42K* entries in this list with about *400K* calls to
> getOrCreateIndex() resulting in over *9 billion* calls to NodeId.equals()=
.
> =A0By combining a HashMap with the ArrayList and checking the HashMap ins=
tead
> of the ArrayList to see if the node is in the cache, we traded the 400K
> calls to ArrayList.indexOf() (and the subsequent 9 billions calls to
> NodeId.equals()) for 400K calls HashMap.get() (and its subsequent calls).
> =A0Our commit time went from about 30 minutes to about 3 minutes.
>
> There may be more elegant ways to fix this problem, but our changes to
> AbstractRecord are listed below. =A0Maybe some changes along these lines =
could
> be incorporated into this class to improve performance. =A0Thanks.
>
> -------------------- old code --------------------
>
> private int getOrCreateIndex(NodeId nodeId) {
> =A0 int index =3D uuidIndex.indexOf(nodeId);
>
> =A0 if (index =3D=3D -1) {
> =A0 =A0 =A0 uuidIndex.add(nodeId);
> =A0 }
> =A0 return index;
> }
>
> -------------------- new code --------------------
>
> private final HashMap<String, Integer> uuidMap =3D new HashMap<String,
> Integer>();
>
> private int getOrCreateIndex(NodeId nodeId) {
> =A0 Integer index =3D uuidMap.get(nodeId.toString());
>
> =A0 if (index =3D=3D null) {
> =A0 =A0 =A0 uuidIndex.add(nodeId);
> =A0 =A0 =A0 uuidMap.put(nodeId.toString(), uuidIndex.size() - 1);
> =A0 =A0 =A0 index =3D -1;
> =A0 }
> =A0 return index;
> }
>
>