I would agree with Axel, that while gob is convenient, it never claims to be optimal. And if you care about size and speed of encoding then it may be worth looking at other serialisation formats.
See https://ugorji.net/blog/benchmarking-serialization-in-go for some alternatives.... On Sunday, 4 April 2021 at 23:43:31 UTC+1 ren...@ix.netcom.com wrote: > Since Dimension can hold any instance type it needs to encode each type > for each element of the slice. I would file an enhancement to use RLE when > encoding interface slices. It won’t be backwards compatible though. > > On Apr 4, 2021, at 10:22 AM, 'Axel Wagner' via golang-nuts < > golan...@googlegroups.com> wrote: > > > > Oh, I should also not, to be fair: You *can* decode the gob into an > `[]Dimension`, but you *can't* do the same with json. So, the comparison > with json is unfair insofar, as the encoded json is actually incomplete - > it doesn't hold the type-information of *which* `Dimension` implementation > to use. > > On Sun, Apr 4, 2021 at 5:18 PM Axel Wagner <axel.wa...@googlemail.com> > wrote: > >> I believe it is expected behavior (well… given that the gob format is >> pretty much defined as "whatever the gob package does", it surely is, at >> this point). >> gob is able to decode types completely, without having a "framework" to >> work on - you need to pass a pointer to `json.Unmarshal`, so that the >> decoder knows what you expect, but that isn't necessary with gob. It does >> that by encoding interfaces using their type-name, followed by their value >> and then looking up the type-name when decoding (which is why you have to >> `gob.Register`). Note that a `[]Dimension` *can* be heterogenous, that is, >> it doesn't have to contain only one type of value. If you look at a hexdump >> of your data, you'll see that's what's happening - every point gets a >> `main.Point` in the output. >> >> You are correct, that gob is not super efficient in this case. There >> probably would be a denser packing (where, instead of a type-name, you use >> an index into an implicit table, for example). But at this point, it's just >> how gob works. I said it before and I say it again: I don't believe gob is >> a very good encoding format. It is convenient to use, in Go, but IMO it >> also comes with significant drawbacks. You might want to look into, say, >> protobuf. >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF1cA9_QRB8BTKiO8zqfV%2Bjz-ZRQ67ZJrujOArBH5W9yw%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF1cA9_QRB8BTKiO8zqfV%2Bjz-ZRQ67ZJrujOArBH5W9yw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b2f8df4d-b49d-436f-9ef0-086c4d5acb57n%40googlegroups.com.
