When I first ran this experiment I didn't realize how extension markers
really worked, and I concluded erroneously that there was a significant
benefit to using a sequence of choices.
In a new test I used the extension markers properly, which gets rid of
the huge difference between adding a new choice vs. adding a new
optional member to a type. To test, I created 100 extensions, and then
used some subset of those in a real example. The results are:
Number used Optional size Choice size
0 84 90
1 106 100
2 115 110
3 124 120
4 133 130
5 142 140
6 151 150
7 160 161
8 169 172
9 178 183
10 187 195
20 277 298
As you can see using optional members ("optional size") is generally
smaller, except when there are between 1 and 6 extensions used. Even
then the largest difference is 5 bytes.
Size aside, using optional members makes the code (both schema and
description) slightly shorter and easier to read.
examples/debug_module.jer is 16B in UPER
examples/example.jer is 84B in UPER
When I first ran this experiment I didn't realize how extension markers really worked, and I concluded erroneously that there was a significant benefit to using a sequence of choices.
In a new test I used the extension markers properly, which gets rid of the huge difference between adding a new choice vs. adding a new optional member to a type. To test, I created 100 extensions, and then used some subset of those in a real example. The results are: Number used Optional size Choice size 0 84 90 1 106 100 2 115 110 3 124 120 4 133 130 5 142 140 6 151 150 7 160 161 8 169 172 9 178 183 10 187 195 20 277 298
As you can see using optional members ("optional size") is generally smaller, except when there are between 1 and 6 extensions used. Even then the largest difference is 5 bytes.
Size aside, using optional members makes the code (both schema and description) slightly shorter and easier to read.
examples/debug_module.jer is 16B in UPER examples/example.jer is 84B in UPER