I believe that WriteMore should not call Flush for these reasons:
1. This is surprising for users because of inconsistency. Why call Flush in
WriteMore and not in WriteObjectEnd?
2. It is not necessary; callers are free to call Flush if their use case demands
it.
3. It harms performance in the common case by flushing the buffer much more
frequently than it needs to be flushed.
The stream benchmark shows a 7% benefit to removing the Flush call, and I
observed a similar speedup in my real-world use case.
benchmark old ns/op new ns/op delta
Benchmark_encode_string_with_SetEscapeHTML-8 442 437 -1.13%
Benchmark_jsoniter_large_file-8 21222 21062 -0.75%
Benchmark_json_large_file-8 40187 40266 +0.20%
Benchmark_stream_encode_big_object-8 8611 7956 -7.61%
benchmark old allocs new allocs delta
Benchmark_encode_string_with_SetEscapeHTML-8 6 6 +0.00%
Benchmark_jsoniter_large_file-8 78 78 +0.00%
Benchmark_json_large_file-8 13 13 +0.00%
Benchmark_stream_encode_big_object-8 0 0 +0.00%
benchmark old bytes new bytes delta
Benchmark_encode_string_with_SetEscapeHTML-8 760 760 +0.00%
Benchmark_jsoniter_large_file-8 4920 4920 +0.00%
Benchmark_json_large_file-8 6640 6640 +0.00%
Benchmark_stream_encode_big_object-8 0 0 +0.00%
Backwards compatibility - I believe there is little to no risk that this breaks
callers. WriteMore does not leave the JSON in a valid state, so it must be
followed by other Write* methods. To get the finished JSON out, the caller must
already be calling Flush.
Previously it would append to the end of the buffer instead of reusing the
now-free space.
Benchmark demonstrates the improvement, run with -benchtime=10s
benchmark old ns/op new ns/op delta
Benchmark_encode_string_with_SetEscapeHTML-8 447 442 -1.12%
Benchmark_jsoniter_large_file-8 20998 21222 +1.07%
Benchmark_json_large_file-8 39593 40187 +1.50%
Benchmark_stream_encode_big_object-8 10787 8611 -20.17%
benchmark old allocs new allocs delta
Benchmark_encode_string_with_SetEscapeHTML-8 6 6 +0.00%
Benchmark_jsoniter_large_file-8 78 78 +0.00%
Benchmark_json_large_file-8 13 13 +0.00%
Benchmark_stream_encode_big_object-8 31 0 -100.00%
benchmark old bytes new bytes delta
Benchmark_encode_string_with_SetEscapeHTML-8 760 760 +0.00%
Benchmark_jsoniter_large_file-8 4920 4920 +0.00%
Benchmark_json_large_file-8 6640 6640 +0.00%
Benchmark_stream_encode_big_object-8 10056 0 -100.00%
Fixes#438
When invalid types inside a map were marshalled (in general, as soon as
sorted maps have been configured), the error message has not been
propagated out of the map's `subStream`.
Also fix and re-enable the channel test, which now resembles the
behavior of `encoding/json` and tests both default and compatible
configurations.
Signed-off-by: Jens Erat <email@jenserat.de>
Defaults to 10,000 to match the existing maxDepth constant everywhetre,
except when using `ConfigCompatibleWithStandardLibrary` - which retains
the limitless depth (and causes a stack overflow).
Added tests for the new config, and also up to jsoniter's stack overflow limit.
[]byte or []uint8 are encoded as base-64 encoded string. Per this, non-nil
empty slice should not get marshalled as null, rather as "".
This restores compatibility with the standard library.
