You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2005/10/03 11:51:49 UTC
[jira] Created: (JCR-235) Cache jcr name to QName mappings
Cache jcr name to QName mappings
--------------------------------
Key: JCR-235
URL: http://issues.apache.org/jira/browse/JCR-235
Project: Jackrabbit
Type: Improvement
Components: core
Reporter: Marcel Reutegger
Priority: Minor
Attachments: QNameResolver.patch
Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
Testing with common read operations shows a performance improvement of about 25%.
The test involved the following methods on Node interface:
- getProperty()
- getProperties()
- getName()
- getPath()
- isLocked()
- isNodeType()
- getPrimaryNodeType()
- hasNodes()
- getNodes()
Attached proposed implementation of a QNameResolver.
Please comment.
--
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
[jira] Commented: (JCR-235) Cache jcr name to QName mappings
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=comments#action_12331697 ]
Marcel Reutegger commented on JCR-235:
--------------------------------------
Ok, here is a second version of the QName caching patch.
- moved name related classes and interface into package o.a.j.name
- getQName() and getJCRName() added to NamespaceResolver interface
- AbstractNamespaceResolver provides optional support for NamespaceListener
- CachingNamespaceResolver implemented as decoration on AbstractNamespaceResolver
- NamespaceRegistryImpl used caching per aggregation (not inheritance)
Currently also LocalNamespaceMappings caches QName resolution, but I think we should only cache mappings on the global NamespaceRegistryImpl. So I'm tempted to remove the caching again from LocalNamespaceMappings. Thoughts on that?
I kept the static methods in QName because I think that's the place they belong to. The class implements the JCR specification of a QName and should therefore also provide a parse facility that is according to the spec.
The patch only include changes on NodeImpl and PropertyImpl to use the new methods in NamespaceResolver, even though there are now many more places in the code that can benefit from the added getQName() and getJCRName() methods in NamespaceResolver. I suggest to change the rest of the code later, after this patch is accepted and committed.
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Stefan Guggisberg
> Priority: Minor
> Fix For: 1.0
> Attachments: QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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
[jira] Commented: (JCR-235) Cache jcr name to QName mappings
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=comments#action_12331774 ]
Jukka Zitting commented on JCR-235:
-----------------------------------
+1
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Stefan Guggisberg
> Priority: Minor
> Fix For: 1.0
> Attachments: QNameCaching.patch, QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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
[jira] Assigned: (JCR-235) Cache jcr name to QName mappings
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=all ]
Stefan Guggisberg reassigned JCR-235:
-------------------------------------
Assign To: Stefan Guggisberg
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Stefan Guggisberg
> Priority: Minor
> Attachments: QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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
[jira] Updated: (JCR-235) Cache jcr name to QName mappings
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=all ]
Marcel Reutegger updated JCR-235:
---------------------------------
Attachment: QNameResolver.patch
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Priority: Minor
> Attachments: QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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
[jira] Commented: (JCR-235) Cache jcr name to QName mappings
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=comments#action_12331871 ]
Stefan Guggisberg commented on JCR-235:
---------------------------------------
+1
i am gonna commit the patch, thanks!
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Stefan Guggisberg
> Priority: Minor
> Fix For: 1.0
> Attachments: QNameCaching.patch, QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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
[jira] Kommentiert: (JCR-235) Cache jcr name to QName mappings
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=comments#action_12331151 ]
Felix Meschberger commented on JCR-235:
---------------------------------------
Shouldn't the QNameResolver interface be placed in the name package just like the QName class itself ?
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Stefan Guggisberg
> Priority: Minor
> Attachments: QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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
[jira] Updated: (JCR-235) Cache jcr name to QName mappings
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=all ]
Jukka Zitting updated JCR-235:
------------------------------
Fix Version: 1.0
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Stefan Guggisberg
> Priority: Minor
> Fix For: 1.0
> Attachments: QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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
[jira] Commented: (JCR-235) Cache jcr name to QName mappings
Posted by "Tobias Strasser (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=comments#action_12331703 ]
Tobias Strasser commented on JCR-235:
-------------------------------------
+1 looks good
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Stefan Guggisberg
> Priority: Minor
> Fix For: 1.0
> Attachments: QNameCaching.patch, QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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
[jira] Closed: (JCR-235) Cache jcr name to QName mappings
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=all ]
Stefan Guggisberg closed JCR-235:
---------------------------------
Resolution: Fixed
applied the patch (r314827)
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Stefan Guggisberg
> Priority: Minor
> Fix For: 1.0
> Attachments: QNameCaching.patch, QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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
[jira] Commented: (JCR-235) Cache jcr name to QName mappings
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=comments#action_12331487 ]
Marcel Reutegger commented on JCR-235:
--------------------------------------
Thank you all for your suggestions I'll post a new patch soon that incorporates your thoughts.
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Stefan Guggisberg
> Priority: Minor
> Fix For: 1.0
> Attachments: QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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
[jira] Updated: (JCR-235) Cache jcr name to QName mappings
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=all ]
Marcel Reutegger updated JCR-235:
---------------------------------
Attachment: QNameCaching.patch
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Stefan Guggisberg
> Priority: Minor
> Fix For: 1.0
> Attachments: QNameCaching.patch, QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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
[jira] Commented: (JCR-235) Cache jcr name to QName mappings
Posted by "Tobias Strasser (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=comments#action_12331150 ]
Tobias Strasser commented on JCR-235:
-------------------------------------
suggest to extends the NamespaceResolver interface by the respective QName translation methods. This would enable a broader usage of an eventual cache. fruthermore could the session local namespace/qname resolvers be sensitive to local namespace mappings.
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Stefan Guggisberg
> Priority: Minor
> Attachments: QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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
[jira] Commented: (JCR-235) Cache jcr name to QName mappings
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-235?page=comments#action_12331171 ]
Jukka Zitting commented on JCR-235:
-----------------------------------
Sounds great! +1 from me, especially the LRUMap is a nice touch, no need to worry about DoS threats due to this.
Design comment: The NamespaceRegistryImpl dependency seems out of place. How about the following structure?
org.apache.jackrabbit.name:
public interface NamespaceListener
public interface QNameResolver
public class StandardQNameResolver implements QNameResolver
public class CachingQNameResolver implements QNameResolver, NamespaceListener
The static QName.toJCRName and QName.fromJCRName methods could be moved to StandardQNameResolver to simplify the QName class.
The CachingQNameResolver could be implemented as a decorator on top of another QNameResolver implementation (StandardQNameResolver by default).
Client code should register and deregister the CachingQNameResolver as a namespace change listener.
This structure would add a tiny amount of overhead (a virtual vs. a static method call + some extra object instances), but would IMHO add much flexibility to the resolution process while keeping the package boundaries nice and solid.
> Cache jcr name to QName mappings
> --------------------------------
>
> Key: JCR-235
> URL: http://issues.apache.org/jira/browse/JCR-235
> Project: Jackrabbit
> Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Stefan Guggisberg
> Priority: Minor
> Attachments: QNameResolver.patch
>
> Currently jcr names are always parsed and resolved into QName instances. Introducing a cache would increase performance and also save memory because well known and often used jcr names would always return the same QName instance from cache.
> Testing with common read operations shows a performance improvement of about 25%.
> The test involved the following methods on Node interface:
> - getProperty()
> - getProperties()
> - getName()
> - getPath()
> - isLocked()
> - isNodeType()
> - getPrimaryNodeType()
> - hasNodes()
> - getNodes()
> Attached proposed implementation of a QNameResolver.
> Please comment.
--
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