個人的なシリアライザの特徴表(まだ試行錯誤中)
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

Comment only
 
ABCDEFGHIJKLMNOPQRSTUVWXYZAAABACAD
1
ワイヤフォーマットリリース後変更(*1)性能安全性仕様関連想定その他
2
IDL(*1)型情報要素識別
サイズ
埋込(*1)
Endian追加削除
要素名
変更(*1)
サイズ速度型検査最大要素
サイズ
整数範囲上位層備考
3
Protocol Buffers
✕(*1)番号
(IDL手動)
Little〇(*1)高速
スタブが要素の型&
全体の整合性を確認
2^31-164bitgRPC?
要IDL=定義が明確化(中規模以上で効果大)。
IDL/スタブ生成必須でお手軽利用には向かない。
proto 3で、より性能寄りに変化?
4
MessagePack要素名Little高速シリアライザが
要素の型を確認。
2^32-164bit
IDL不要。
型情報を埋め込みが面白い。
5
JSON〇(*2)要素名✕(*2)なし中(*1)シリアライザが
要素の型を確認。
なし?
64bit float
≒ 整数は
53bit範囲
ワイヤフォーマットを理解しやすい。
JSON Schemaで検査可能になってきた?
6
XDR番号
(IDL自動)
✕(*3)Big(*1)✕(*2)高速
スタブが要素の型&
全体の整合性を確認
2^32-1?64bitSunRPC
ある意味単純。
ワイヤフォーマットはSunの生表現に近い。
7
8
(*1) 明示的なスキーマ定義を行うかどうか
9
10
(*1) 3bitのタイプ情報(グループ化)は存在
11
(*2) "" は文字列、数字は浮動小数点、{} は辞書、[] は配列、といった程度
12
13
(*1) パース時の性能が出しやすい(&検査しやすさ)
14
(*2) 文字列自身で終端を表現
15
(*3) 可変長配列は埋込、それ以外はIDL情報で決め打ち
16
17
(*1) MS-RPC(DCE-RPC系NDR) の場合、送信側ネイティブなエンディアンを使用(受信側でエンディアン変換)
18
19
(*1) 古いリリースが、変更後フォーマットに耐えらるか(削除の場合、利用側での事前想定も必要)
20
(*2) 基本的には、追加=プログラム番号を上げて、従来プログラムとは通信しないイメージ
21
22
(*1) Proto3 以降は required が無くなり、すべて無効化可能に
23
24
(*1) ≒ 要素識別をID化しているかに依存
25
26
(*1) 元々は遅かったが、多用につれ、SIMDチューンなどで改善
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...