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 serial
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,
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
> 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.
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
d
Hi,
Gob in general is pretty efficient however I am seeing, what seems to be an
anomaly in its behavior when it comes to serilazing interfaces.
To elaborate, I have a program defining a simple interface called Dimension
and a struct Point.
*type Dimension interface{}*
*type Point struct {*
* X,
