Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <1455472441.1248437594793.JavaMail.jira@brutus>
Date: Fri, 24 Jul 2009 05:13:14 -0700 (PDT)
From: =?utf-8?Q?Michael_D=C3=BCrig_=28JIRA=29?= <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-2218) NodeEntryImpl.getWorkspaceId() very
 inefficient
In-Reply-To: <1713789777.1247752934828.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/JCR-2218?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D127350=
39#action_12735039 ]=20

Michael D=C3=BCrig commented on JCR-2218:
------------------------------------

I just checked the effect of an alternative approach: call site caching of =
IdFactory calls.=20

public NodeId getId() throws InvalidItemStateException, RepositoryException=
 {
    IdFactory idFactory =3D getIdFactory();
    PathFactory pathFactory =3D getPathFactory();
    IdCache idCache =3D getIdCache();

    if (uniqueID !=3D null) {
        NodeId nodeId =3D idCache.get(uniqueID);
        if (nodeId =3D=3D null) {
            nodeId =3D idFactory.createNodeId(uniqueID);
            idCache.put(uniqueID, nodeId);
        }
        return nodeId;
    }
    else if (parent =3D=3D null) { // root
        NodeId nodeId =3D idCache.get("ROOT"); =20
        if (nodeId =3D=3D null) {
            nodeId =3D idFactory.createNodeId((String) null, pathFactory.ge=
tRootPath());
            idCache.put("ROOT", nodeId); =20
        }
        return nodeId;
    }
    else {
        NodeId parentId =3D parent.getId();
        Name name =3D getName();
        int index =3D getIndex();
        NodeId nodeId =3D idCache.get(parentId, name, index);
        if (nodeId =3D=3D null) {
            Path path =3D pathFactory.create(name, index);
            nodeId =3D idFactory.createNodeId(parentId, path);
            idCache.put(parentId, name, index, nodeId);
        }
        return nodeId;
    }
}

My profiling shows, that there is nothing much to be gained from this. This=
 is in line with an earlier observation, that looking up ItemIds from a has=
h map comes with about the same cost as creating new itemIds. The main cont=
ribution coming from the equals and hashCode methods from the various class=
es involved when comparing ItemIds.=20


> NodeEntryImpl.getWorkspaceId() very inefficient=20
> ------------------------------------------------
>
>                 Key: JCR-2218
>                 URL: https://issues.apache.org/jira/browse/JCR-2218
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Michael D=C3=BCrig
>
> NodeEntryImpl.getWorkspaceId() calculates its path on each call by callin=
g itself recursively. Further each call to getWorkspaceId() results in vari=
ous calls to the path and item factories which might be somewhat expensive =
by themselves.=20
> In my test scenario I have a RepositoryService.getItemInfos() call return=
ing ~1000 items. Processing these items results in about 2700000 (!) calls =
to getWorkspaceId(). Profiler data shows, that 98% of the time to process t=
he 1000 items is spent in getWorkspaceId()  and related calls.=20

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.