On 2015-01-24, Stefan Bodewig wrote: > On 2015-01-23, Emmanuel Bourg wrote:
>> - BitInputStream: why not using a long cache instead of an int, like >> BitStream before the refactoring? It might be interesting to do some >> benchmarks and see if it make a difference. > We never needed more than 31 bits, but you are right, I'll try to > experiment a little. I've changed ot to use a long internally but it won't have any effect. The way it is implemented we never read more bytes than are needed to fulfill the current readBits request. This means there will be no difference in I/O between using a long or an int as cache. There may be a small difference between the bit operations but my micro-benchmarks are not conclusive. Since CC never uses more than 31 bits, we will never use the upper four bytes of the cache. We may want to change the implementation to eagerly try to cache more in a future release. Still I switched to long now because this allowed me to change the return type of readBits to long. The class is new, so we can still change the API. If it said int now, we wouldn't be able to change it later. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
