[ https://issues.apache.org/jira/browse/JCR-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-3721: ------------------------------- Fix Version/s: 2.6.6 Merged to the 2.6 branch in revision 1566708. > Slow and actively called NodeId.toString() > ------------------------------------------ > > Key: JCR-3721 > URL: https://issues.apache.org/jira/browse/JCR-3721 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core > Affects Versions: 2.6.5, 2.7 > Environment: Debian/GNU Linux 7.3 / Oracle JDK 7 / Apache Tomcat 7.0; > Windows Server 2008 / IBM WebSphere AppServer 7.0 > Reporter: Maxim Zinal > Assignee: Jukka Zitting > Fix For: 2.6.6, 2.7.5 > > Attachments: NodeIdToString.patch > > > I performed some JackRabbit profiling while trying to investigate the reason > of low performance of our application. > The mostly interesting thing I've found is that NodeId.toString() method is > heavily used for hierarchy-based XPath queries, and it performs really bad. > This are the numbers for my test application: > - Total CPU time: 879 178 msec > - CPU time in NodeId.toString(), including subcalls: 223 705 msec > A quick check against NodeId.toString() implementation shows that it is based > on UUID.toString(), which itself is very ineffective in both in Oracle and > IBM JDK. > I've wrote a quick replacement for this method, and my measurements show that > overall performance became significantly better for our case. > Hope that this will help to improve JackRabbit performance for similiar > applications. > P.S. Another interesting thing I've found is that a lot of time is spent > inside log4j.Category.getEffectiveLevel() method - I suspect this is caused > by numerous log.debug() calls without proper isDebugEnabled() handling. -- This message was sent by Atlassian JIRA (v6.1.5#6160)