[
https://issues.apache.org/jira/browse/CLEREZZA-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982150#action_12982150
]
Rupert Westenthaler commented on CLEREZZA-395:
----------------------------------------------
I think the only reason why the map is needed is because in Clerezza BNode does
not allow to define an ID.
If BNode would have an ID, than one could set this ID to the same value as
Node.getBlankNodeId().toString(). If the BNode implementation would than use
this ID for the implementation of hash() and equals, than having multiple
instances for one and the same blank node in the jena graph should not be a
problem anymore and one would no longer need the bidirectional mapping.
BNode could still use the hash() and equals() implementation of
java.lang.Object() if no ID is parsed in the constructor so there should be no
influence at existing Code.
WDYT
Rupert Westenthaler
> bnodes mapping in JenaGraphAdaptor should not keep growing with every parsing
> of rdf files
> ------------------------------------------------------------------------------------------
>
> Key: CLEREZZA-395
> URL: https://issues.apache.org/jira/browse/CLEREZZA-395
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Hasan
> Assignee: Hasan
>
> With every parsing of rdf files free memory is getting less.
> The problem seems to lie in the JenaGraphAdaptor class
> It has a member:
> final BidiMap<BNode, Node> tria2JenaBNodes = new BidiMapImpl<BNode, Node>();
> which grows each time a serialized graph get parsed.
> My experiments with my test data show
> At the end of the 1st parsing: Size of tria2JenaBNodes = 87200
> At the end of the 2nd parsing: Size of tria2JenaBNodes = 130800
> At the end of the 3rd parsing: Size of tria2JenaBNodes = 174400
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
