[ 
http://issues.apache.org/jira/browse/JCR-688?page=comments#action_12460349 ] 
            
Jukka Zitting commented on JCR-688:
-----------------------------------

> The following test case executes 5 times faster with name caching

Good point. :-)

Digging deeper in the performance figures I noticed that most of this 
performance hit is caused by the heavy use of regexp matching in NameFormat. I 
was able to get a major performance gain simply by replacing the regexp's with 
custom parsing code (I'll clean it up attach as an example patch). The 
performance is still clearly worse than with caching, but not nearly as bad as 
before.

Some other observations:

* The performance requirements and expected data sets for the QName->String and 
String->QName conversions seem quite different. For example the above test case 
is almost entirely governed by the String->QName conversion speed. It would 
probably make sense to consider using separate mechanisms for the two types of 
conversions.

* Moving the name cache from the global namespace registry to the session level 
would probably make sense. That would avoid the synchronization requirements at 
the expense of extra memory use. An extra benefit would be that the name cache 
could also be used when session-local namespace remappings are in effect.

* The individual resolution operations are very fast in any case, so the 
performance is only relevant when doing a large number of operations. Thus the 
cost of occasional heavier optimization operations (if available) could 
probably be easily amortized.


> Improve name resolution
> -----------------------
>
>                 Key: JCR-688
>                 URL: http://issues.apache.org/jira/browse/JCR-688
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: core
>            Reporter: Jukka Zitting
>            Priority: Minor
>             Fix For: 1.3
>
>
> As discussed in JCR-685, the current CachingNamespaceResolver class contains 
> excessive synchronization causing monitor contention that reduces performance.
> In JCR-685 there's a proposed patch that replaces synchronization with a 
> read-write lock that would allow concurrent read access to the name cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to