netty-vbuf

Variable length encoding ByteBuf implementation.

Overview

This is a ByteBuf implementation, that's using variable length encoding for ints and longs to save memory consumption and eventually cpu time.

Get it

from Maven Central

<dependency>
    <groupId>de.knutwalker</groupId>
    <artifactId>netty-vbuf</artifactId>
    <version>0.1.3</version>
</dependency>

from release binary

Download the netty-vbuf-0.1.3.jar of the latest release and place it in your classpath.

from source

Clone this repo and run mvn package -DskipTests and then add the target/netty-vbuf-0.1.4-SNAPSHOT.jar jar to your classpath.

Use it

import io.netty.buffer.VByteBuf;
...
ByteBuf vBuf = VByteBuf.wrap(existingByteBuf);

The methods set, get, read, and write for both, Int and Long are reimplemented, all others delegate to the wrapped buffer.

Profit

Variable length encoding used the highest bit of each byte to encode whether the next byte belongs to the current number. This allows for an int to be encoded in 1 to 5 bytes. If you're encoding primarily small numbers, using a variable length encoding can drastically save memory consumption.

These are some examples for the different encodings

int	regular encoding	variable length encoding	memory savings
42	00000000 00000000 00000000 00101010	00101010	75%
1337	00000000 00000000 00000101 00111001	10001010 00111001	50%
134217728	00001000 00000000 00000000 00000000	11000000 10000000 10000000 00000000	0%
2147483647	01111111 11111111 11111111 11111111	10000111 11111111 11111111 11111111 01111111	-25% (loss)

If you write many small numbers to a ByteBuf, that isn't over sized and needs to resize once in a while, using variable length encoding can reduce the number of costly memory copy operations and therefore reduce used cpu time.

Otherwise, the encoding adds a runtime overhead, mostly due to the repeated boundary checking for each byte, where the regular encoding would just check once for all bytes.

These are some possible savings, when writing 100M (continuously increasing) longs:

     writing 7-bit long with resizing used 87.50% less memory and 95.14% less time
   writing growing long with resizing used 50.26% less memory and 69.69% less time
  writing 7-bit long without resizing used 87.50% less memory and 31.83% less time
writing growing long without resizing used 50.26% less memory and 242.82% more time

These are just nanoTimes, so no real, useful benchmarks, but they give a hint in the right direction.