Re: timestamps encoding (was: Re: Straw Poll: Restore Header Table and Static Table Indices)

["Martin Nilsson" <[e-mail]>]

On Tue, 21 Oct 2014 16:24:51 +0200, Willy Tarreau <[e-mail]> wrote:

>
> The example code below converts valid strings to their compacted form
> and leaves the non-convertable ones intact. The converted string's format
> indicates what format it's in (ie: if it begins with 0xA its a compact  
> one).
> The gains are interesting, just tested on example.com, there are 3 dates
> there, 24 bytes each, and reduced to 5 bytes each, that's 57 bytes saved
> in one response header (19 bytes saved per valid header).
>

That's before huffman encoding.

Taking a now:ish timestamp of 1413938411 creates the byte sequence  
0a.84.89.46.56. These 5 bytes are encoded with 89 bits after huffman  
encoding, whereas the 10 byte numeric literal "1413938411" is encoded with  
56 bits. Not completely fair since you have an encoding token in front,  
which is needed here to distinguish between time and time offsets. If we  
pick "t" to mean time, which is encoded with 5 bits, we get 64 bits for  
your method and 61 bits for ASCII, for this example. For this size of  
numbers you'll get an average of 4*18.2 = 72.8 bits while ASCII gives  
10*5.7 = 57 bits (plus encoding token).

/Martin Nilsson

-- 
Using Opera's mail client: http://www.opera.com/mail/