Do you mean to write a specific BitSet using one long type as its internal storage to deal with <=64 elements enums?
No, I suggest to implement a specific EnumSet using one long type. My opinion is that a specific <=64 BitSet wouldn't be very useful. On 8/4/06, Spark Shen <[EMAIL PROTECTED]> wrote:
Oleg Khaschansky 写道: > 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. Do you mean to write a specific BitSet using one long type as its internal storage to deal with <=64 elements enums? > 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. Thank you very much for your suggestion. Best regards. > > 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] > > -- 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]
