speed up encoding/json

[Doug]

As a proof of concept, I've made some changes to the JSON encoder in
an attempt to speed things up. My experiment was moderately
successful -- approximately 25% faster at encoding, at least according
to go test encoding/json -bench '.*' (42 Mb/s vs 33Mb/s on my Macbook
Air for BenchmarkCodeEncoder).

The downside is that I ended up changing the interface such that the
marshaling functions take an byte slice as an argument, and append
their output to the slice.

func Marshal(v interface{}) ([]byte, error)
type Marshaler interface {
func MarshalJSON() ([]byte, error)
}

becomes:

func Marshal(out []byte, v interface{}) ([]byte, error)
type Marshaler interface {
func MarshalJSON(out []byte) ([]byte, error)
}

I also dropped the call to Compact on the output of MarshalJSON, so
the results aren't the same.

Is there any interest in this approach (should I clean it up and
submit a patch)? Or do the drawbacks outweigh the benefits?

-Doug

[Rob 'Commander' Pike]

The APIs are frozen for Go 1.

-rob

[Doug]

That seems like a much stronger argument if Go 1 were actually
released, or if the release were very close. If it were felt that
something like this was otherwise a desirable change, wouldn't it make
sense to make such the change before the release of Go 1? Or are you
implying that the Go 1 release *is* very close. I would take that as
good news.

Of course, you may just not like the change, and that's fine too.

-Doug

[DisposaBoy]

I think he's implying that the window for such changes is closed and I believe it has been for some time. The window has to close at some point otherwise nothing gets done, and if it does what often happens is that things break - badly - because they haven't been though through enough with regards to how everything fits together.

[Rob 'Commander' Pike]

On Jan 28, 2012, at 9:06 AM, DisposaBoy wrote:

> I think he's implying that the window for such changes is closed and I believe it has been for some time. The window has to close at some point otherwise nothing gets done, and if it does what often happens is that things break - badly - because they haven't been though through enough with regards to how everything fits together.

Yes, that's the story. We're fixing bugs, writing documentation, cross-checking everything for consistency. Things need to stabilize well before the release actually happens.

And the release is pretty close. The current weekly is very close to what will be Go 1. If someone writes code that works in the weekly, it is almost certain to work with the official Go 1 release.

-rob

[Doug]

Then I'll take that as good news. Thanks.

-Doug

[Doug]

Is there any interest in patches that speed things up without changing
the public interface? I was able to redo things to keep most of the
speed gains without changing the public interface.

-Doug

[Nigel Tao]

On 29 January 2012 13:40, Doug <dougla...@gmail.com> wrote:
> Is there any interest in patches that speed things up without changing
> the public interface?  I was able to redo things to keep most of the
> speed gains without changing the public interface.

Not now. Maybe later.

[Doug]

No problem -- I assume the implication is to wait until after the
release of 1.0?

-Doug

On Jan 28, 7:04 pm, Nigel Tao <nigel...@golang.org> wrote:

[Andrew Gerrand]

Yes. Once the Go 1 release is out the door we'll be ready to review performance improvements, but we will still refuse backward-incompatible API changes.

Andrew