Thanks everyone for the insights and suggestions. On Monday, 5 April 2021 at 13:47:20 UTC+8 Amnon wrote:
> 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/f22b5e27-d125-4800-beb2-04b09576cdean%40googlegroups.com.
