jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1214) DocId.UUIDDocId should not have a string attr uuid
Date Mon, 19 Nov 2007 11:37:43 GMT

    [ https://issues.apache.org/jira/browse/JCR-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543530
] 

Ard Schrijvers commented on JCR-1214:
-------------------------------------

"For simplicity I would rather use an instance of UUID instead of two longs. " 

By the way I think the overhead of a UUID instance (12-16 bytes for an Object) seems to me
redundant if only storing 2 longs is enough. My intention was to reduce memory consumption
for the string uuid ( ~120 bytes) to two long's. Ofcourse, a UUID instance is still smaller
than the original 120 bytes but still uses redundant memory (though I admit probably UUID
instances are small enough :-) )

Thx for solving the issue! 

> DocId.UUIDDocId should not have a string attr uuid
> --------------------------------------------------
>
>                 Key: JCR-1214
>                 URL: https://issues.apache.org/jira/browse/JCR-1214
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: query
>    Affects Versions: 1.3.3
>            Reporter: Ard Schrijvers
>            Assignee: Marcel Reutegger
>             Fix For: 1.4
>
>
> After JCR-1213 will be solved, lots of DocId.UUIDDocId can be cached, and not being cleaned
after every gc(). The number of cached UUIDDocId can grow very large, depending on the size
of the repository.  Therefor, instead of storing the private String uuid; we can make it more
memory efficient by storing 2 long's, the lsb and msb of the uuid.  Storing 1.000.000 of parent
UUIDDocId might differ about 100Mb of memory. 
> I even did test by removing the entire uuid string, and not use msb or lsb, because,
when everything works properly (with references to index reader segments (See JCR-1213)),
the uuid is never needed again: in 
> UUIDDocId getDocumentNumber(IndexReader reader) throws IOException {
> we could set uuid = null just before the return. It works perfectly well, because when
an index reader is recreated, the CachingIndexReader will be recreated, hence DocId[] parents
will be recreated. 
> So, IMO, I think we might be able to remove the uuid entirely when the docNumber is found
in DocId.UUIDDocId (obviously after JCR-1213)
> WDOT?

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