coip/jsonvgob

attempt @ an apples to apples take on encoding deltas

take a look at the diff file for a ~patch of changes/overhead necessary for shifting from json encoding to gob encoding. that overhead in vim looks like :%s/json/gob/g... so one command :)

results

json: first 100B

ethan@vanitas:~/xmljson$ ./jsonencoded | head -c 100 && echo ""
{"employees":[{"firstName":"John","lastName":"Doe the 1th"},{"firstName":"John","lastName":"Doe the

gob: first 100B

ethan@vanitas:~/xmljson$ ./gobencoded | head -c 100 && echo ""
����    Employees� ����E�   �����[]main.Employee� �  1��Employee� ���   FirstName� L

seen here, JSON may be better for small/discrete payloads given some of the upfront cost of gobs, but the gob deduplication pays off at scale. amortization anybody?

gob: first 220B

ethan@vanitas:~/xmljson$ ./gobencoded | head -c 220 && echo ""
����    Employees� ����E�   �����[]main.Employee� �  1��Employee� ���   FirstName� LastName�   Uu����John��Doe the 1th ��John��Doe the 2th ��John��Doe the 3th ��John��Doe the 4th ��John��Doe the 5th

net bytes for 1000 Employees below, for each of encoding/{json,gob}:

ethan@vanitas:~/xmljson$ ./gobencoded | wc -c
21992
ethan@vanitas:~/xmljson$ ./jsonencoded | wc -c
47860

---

ps.

gophers speak bits/bytes... 0's and 1's. encoding/gob is a binary encoding.

sending gobs over the *wire(boundary really, local FD even) leverages the gopher language.

humans speak ~ASCII to an extent, and there is of-course value in human-readable -ness.

but TANSTAAFL, and human-readable character encoding is perhaps unnecessary for the gophers.

(id like to acknowledge regarding encoding/transport, i'm a fan of protofbuf/~grpc, and that would be a likely iteration candidate/better direction in lieu of gobs. but this is also a few minutes of thoughts to merely log the json v gob thing I think about from time to time.)

pps

iotas/typedef enumerations also make for a better ~dx in tangentially related cases when developing/consuming an SDK entirely within a go ~ecosystem. ie, enumerating Types of employees, then using the ~iota as the encoded key. much cheaper over the wire than string stuff. (read: firstnames above, if instead were employee-type, and say and example of that being "accounting". instead of encopding that attribute as "accounting", having a lib where ~var AccountingEmployee Employee = iota + c, which is then sent as ~7, say, over the wire. again, 7 instead of ~accounting, so ~10 iota payloads compared to the 1 string assuming 1 int is ~= 1 ascii char.