commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject [compress] BitInputStream (was Preparations for 1.10)
Date Sun, 25 Jan 2015 10:09:20 GMT
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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message