Binary Serialization & Elm
A byte is 8 bits of information
A byte is 8 bits of information
Why Bytes?
Send fewer bytes over the wire?
Take the number `2019`
Format | Representation | Size |
---|---|---|
Json | 2019 | 4 bytes |
Bytes | 00000111 11100011 | 2 bytes |
50% smaller, the gain is larger for larger (i.e. longer) numbers
{
"title": "foo",
"subject": "spam"
}
json stores a lot of structure: key names, {}, "", []
3 f o o 4 s p a m
33 666f6f 34 7370616d
Field | # of bytes | type |
---|---|---|
titleLength | 1 | uint8 |
title | variable | string |
subjectLength | 1 | uint8 |
subject | variable | string |
The Bytes type is a sequence of bytes
Bytes
is to binary serialization what
String
is to json decoders (and parsers in general)
The api looks a lot like json
primitives for
and combinators like map/map2/andThen
So binary serialization is more compact, we should use it right?
type Posix = Posix Int
type alias Item =
{ title : String
, link : String
, media : String
, dateTaken : Posix
, description : String
, published : Posix
, author : String
, authorId : String
, tags : List String
}
Json is 2 times faster!
type alias Vec3 =
{ x : Float, y : Float, z : Float }
type alias Triangle =
{ normal : Vec3, p1 : Vec3, p2 : Vec3, p3 : Vec3 }
Here bytes are much faster
most file types are binary encoded. We can now use them from elm
examples include zip, tar, png, mp3, otf
I decode font files because
font files are segmented into tables
tables are still lists of fields, sizes, types
header table stores info about tables
we have table A and B
table A contains a variable length array, but
table B contains the length of that array
circular dependency
similar but not the same. With json
solution: decode in 2 passes
Dict String Bytes
create decoders for individual tables
data dependencies are decoder arguments
Bytes create many new possibilities