4 ms·

The encoding/gob package has been rewritten to eliminate the use of unsafe operations, allowing it to be used in environments that do not permit use of the unsa

by Strom 12y ago

The encoding/gob package has been rewritten to eliminate the use of unsafe operations, allowing it to be used in environments that do not permit use of the unsafe package. For typical uses it will be 10-30% slower This seems like a highly questionable decision to me. I've invested a lot of time into optimizing my code that uses encoding/gob, so to now get hit by a wholesale 30% slower stamp from the Go team is a bit weird. These environments that can't use encoding/gob with unsafe, can't be that common, however it seems that everyone will suffer from their limitations.

pjmlp 12y ago
Maybe their target is the App engine.
- Strom 12y ago
  It's true that you can't directly import unsafe in your own Go code on App Engine. However importing standard library packages like encoding/gob, which then proceed to use the unsafe package for themselves, works just fine on App Engine. App Engine is actually the biggest reason why I don't immediately like this change. For other environments I can just fork the Go 1.3 encoding/gob implementation and use that. However on App Engine I can't import unsafe myself, so the only way to run really fast unsafe code, is to use the standard library. This latest change removes that option from me.
- enneff 12y ago
  It's more that by removing the use of unsafe it will play more nicely with the new concurrent garbage collector (slated for Go 1.5 in June).
  - pjmlp 12y ago
    Thanks for the heads up. Are also there plans to expose more primitives in unsafe? I remember seeing some posts related to possible required features as part of re-writing the whole stack in Go.
kjksf 12y ago
Trivial solution: "fork" the old, fast version of std library code into its own repo and the only change you need is to import that repo instead of "encoding/gob" I did that few times (mostly in the other direction, where I wanted features from unreleased version of Go)
howeman 12y ago
They also found (and fixed) some bugs and the code will be more robust to future implementation changes.
shurcooL 12y ago
> These environments that can't use encoding/gob with unsafe, can't be that common They aren't, but I will provide one example that benefits from this change. As of 1.4, because of this change, it will be possible [1] to use encoding/gob (and other packages that import it) in the frontend via the GopherJS project. [1] https://github.com/gopherjs/gopherjs/commit/7d67c77e85187c7ff037beca19e3ad77c630e721 https://github.com/gopherjs/gopherjs/commit/7d67c77e85187c7f...
duaneb 12y ago
It would make more sense to me to have an safe but api-compatible library version that doesn't use unsafe. Not a great sign for lib updates in the future.

by Strom 12y ago

pjmlp 12y ago

Maybe their target is the App engine.

Strom 12y ago
It's true that you can't directly import unsafe in your own Go code on App Engine. However importing standard library packages like encoding/gob, which then proceed to use the unsafe package for themselves, works just fine on App Engine. App Engine is actually the biggest reason why I don't immediately like this change. For other environments I can just fork the Go 1.3 encoding/gob implementation and use that. However on App Engine I can't import unsafe myself, so the only way to run really fast unsafe code, is to use the standard library. This latest change removes that option from me.
enneff 12y ago
It's more that by removing the use of unsafe it will play more nicely with the new concurrent garbage collector (slated for Go 1.5 in June).
- pjmlp 12y ago
  Thanks for the heads up. Are also there plans to expose more primitives in unsafe? I remember seeing some posts related to possible required features as part of re-writing the whole stack in Go.

kjksf 12y ago

Trivial solution: "fork" the old, fast version of std library code into its own repo and the only change you need is to import that repo instead of "encoding/gob" I did that few times (mostly in the other direction, where I wanted features from unreleased version of Go)

howeman 12y ago

They also found (and fixed) some bugs and the code will be more robust to future implementation changes.

shurcooL 12y ago

> These environments that can't use encoding/gob with unsafe, can't be that common They aren't, but I will provide one example that benefits from this change. As of 1.4, because of this change, it will be possible [1] to use encoding/gob (and other packages that import it) in the frontend via the GopherJS project. [1] https://github.com/gopherjs/gopherjs/commit/7d67c77e85187c7ff037beca19e3ad77c630e721 https://github.com/gopherjs/gopherjs/commit/7d67c77e85187c7f...

duaneb 12y ago

It would make more sense to me to have an safe but api-compatible library version that doesn't use unsafe. Not a great sign for lib updates in the future.