[
http://jira.jboss.com/jira/browse/JBCACHE-485?page=all ]
Elias Ross updated JBCACHE-485:
-------------------------------
Attachment: set.diff
I lost my CVS commit rights, but anyway here's a patch to make the Set.contains()
add() and remove() implementations be O(1) (more or less.)
If for 2.0, it'd be nice if Fqn in PojoCache could be arbitrary types, then there
wouldn't be any reason to "toString" on the Long.
To fix the List implementation, I guess I would consider two cases separately. There's
the LinkedList and RandomAccess styles of Lists. For LinkedList, you wouldn't have to
worry about get(int i) being O(1) so removes in the middle could be fast. Could you change
the implementation to detect and match closely what the user used?
Refactor the current Collection classes (list and set)
------------------------------------------------------
Key: JBCACHE-485
URL:
http://jira.jboss.com/jira/browse/JBCACHE-485
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Priority: Critical
Fix For: PojoCache
Attachments: set.diff
Original Estimate: 4 weeks
Remaining Estimate: 4 weeks
Current implementation of Collection uses direct coupling to the cache store indices.
E.g., we map them into subtree according to index ordering. This is not very desirable for
performance reason. We should consider to provide a indirect mapping such that it is
considered a graph instead of ordered tree.
Or we should investigate whether it is possible to use a proxy operates on java.util.*
classes such that we don't need to have our own implementation. The JDK lincense
aside, ArrayList, e.g., uses an internal transient array. Is it possible to
"aspectize" on that array only?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira