[
https://jira.jboss.org/jira/browse/JGRP-806?page=com.atlassian.jira.plugi...
]
Michal Frajt commented on JGRP-806:
-----------------------------------
I've reviewed your changes. Here are my comments:
- resize() method
The very common practice in all Collection classes is to double the current size of an
underlying structure. The static increment can be fine as we do not expect more headers to
be added anyway.
- synchronized resize()
Either the class is synchronized or non-synchronized. One synchronized method will not
protected malfunctionality if the object is used from multiple threads without monitor
(adds overwriting same index etc). I do prefer to remove the synchronized to strongly
indicate that the whole Message object is non synchronized data structure.
- garbage less iteration not possible
The only way to iterate over the headers seems to be the method returning constructed
HashMap.
Running a debuging (processing /displaying of headers) would than return the garbage cost
to the previous solution. You should take care that non of the protocol stacks or other
parts of the code are using the getHeaders method frequently. Solution might be to add
methods String getHeaderName(int index) and Header getHeader(int index) for the fast
iterator using the index (see RandomAccess of the ArrayList). The method to return the max
index (getHeaderNum() is already available). The method with HashMap can/must stay for
compatility.
I might come with some more optimalizations of other parts as we are going to continue
with the JGroups testing/integration in next weeks. I just recall that there was some code
like new HashSet(1) for one element. You should use the Colllections.singleton metod for
size 1, Collection.emptySet for empty sets and have your own smart set implementation
(like new Headers) for sets < ~10. It can give same benefits as the current changes
done on the headers.
Michal
Message: investigate making the overhead for headers smaller
------------------------------------------------------------
Key: JGRP-806
URL:
https://jira.jboss.org/jira/browse/JGRP-806
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.6.4, 2.7
Related to
https://jira.jboss.org/jira/browse/JGRP-805.
See whether we can make the overhead for ConcurrentHashmap in Message smaller.
Potentially reduce the number of buckets for each CCHM (default: 16, IIRC). Or replace
CCHMs altogether ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira