incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Westenthaler (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CLEREZZA-395) bnodes mapping in JenaGraphAdaptor should not keep growing with every parsing of rdf files
Date Sat, 15 Jan 2011 18:58:46 GMT

    [ 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.


Mime
View raw message