Yes, I mean exactly one long type, not array. And I think that for this case the code in the BitSet and EnumSet implementation would be pretty simplier and then faster. But the <=64 bit BitSet looks not very useful, so I don't suggest to optimize it. At the same time <=64 elemnts enums are, probably, used much more often and EnumSet could be optimized in this way. It is just a suggestion, hope that it could be useful.
On 8/3/06, Spark Shen <[EMAIL PROTECTED]> wrote:
Oleg Khaschansky 写道: > Hi all! > > I'd like to add to this discussion that, IMHO, implementation of the > EnumSet > based on the BitSet class, probably, would be relatively slow. I can not fully agree with you here. IIRC, BitSet already uses long array to store bits instead of Byte[] in our implementation. Every bit in any long of the long array corresponds to a enum type element. IMHO, this is the most effcient way to store bits. The only down side of using BitSet is that there are extra method invokations. > I'd suggest > to handle extra case when the number of elements in the enum is <= 64 > and it > is possible to represent the set with one long value. For this case > all the > EnumSet API could be implemented using fast bitwise operations. Since the long array storage, no matter the number of elements in an enum type, fast bitwise operations can be applied. Do you mean to do extra optimization when number of elements in enum type is less than 64. Under this condition, may be we can use one long type instead of a long array. But will this kind of optimization bring any bonus is unknown right now. Correct me if I am wrong. Best regards > > Thank you. > -- > Oleg Khaschansky, > Intel MPD > > On 8/3/06, Spark Shen <[EMAIL PROTECTED]> wrote: >> >> Richard Liang 写道: >> > >> > >> > Spark Shen wrote: >> >> Hi All: >> >> >> >> IMHO, EnumSet provides a set view of enum types. According to its >> >> spec, "Enum sets are represented internally as bit vectors". >> >> To avoid to re-invent the wheel, it could be more reasonable to >> >> utilize java.util.BitSet class to support the implementation of >> EnumSet. >> >> >> > Agree :-) >> > >> >> While current API methods provided by BitSet is not enough, I need to >> >> extend the function provided by BitSet. There are 2 options: >> >> 1. Implement these extension methods in BitSet directly as package >> >> private methods >> >> 2. Construct a package private utility class in >> >> org.apache.harmony.luni.util package, and implement extensions in >> >> this implementation class. >> >> >> >> I prefer the first option, since there is not many classes need these >> >> extension. If no objections, I will adopt the first schema. >> >> >> > IMHO, it depends on the relationship between the extended functions >> > and the whole class. Would you please provide more detail information? >> > Thanks a lot. >> 1. It can be simply detected that on RI, EnumSet.noneOf() or >> EnumSet.allOf() method will return a concrete EnumSet. This concrete >> EnumSet provides its own iterator. >> All these iterator related methods are not implemented in BitSet right >> now. >> >> 2. To support the implementation of EnumSet, more utility methods used >> to set/unset bits may need to be added. >> >> All these requirements are EnumSet specific, do they need to be >> implemented in a separate class. >> >> Best regards >> > >> > Richard. >> >> Best regards. >> >> >> > >> >> >> -- >> Spark Shen >> China Software Development Lab, IBM >> >> >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > -- Spark Shen China Software Development Lab, IBM --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]