Re: timestamps encoding

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/10/2014 2:13 p.m., Martin Nilsson wrote:
> On Tue, 21 Oct 2014 16:24:51 +0200, Willy Tarreau 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).


Huffman encoding applies only to String literals. This numeric is an
Integer Literal byte sequence.

Also, if you are going to signal a binary state (delta vs absolute
time) use a 1-bit flag, built into the value type code this wastes no
space. As you can see a separate 5-bit String Literal character just
biases the encoding towards ASCII.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJURxF/AAoJELJo5wb/XPRjbncH/1wuuCk4QoKgeMbm1eNCmCMK
jfrK3T7eIsla1gG0+PBvRPtApidO1QpOwtd2mhN0mkO8vNSWN6GI9N5ECgekOQkP
uh6TthNlh93iWIQubDhy99SmhbkK1Ii21WzAib3pON3g1kscy9XcGQ/07EwJtQxI
7u/VJtg7S09jSQLbPqXOIWyZ3Ws92gGshdbMtyntsOGMSoIahT6Mi5BJFx4kVYK/
Qe3Z4yn7xeusmGBjFNpwbmAOlIE5f5D7/67F/1hNtO9EClEzxAAp4Mevdfk+xruV
b6BNxdkhXTNKbhMMuXbfu+0hB4OeVYRohJmkuY8QQby5YmKMzLyBa4h5z0HAnc8=
=49jx
-----END PGP SIGNATURE-----

Received on Wednesday, 22 October 2014 02:08:35 UTC