Protocol (un)marshallers make many allocations

[jasdel]

The protocol marshallers make numerous allocations when marshaling and unmarshalling structs. This is much more noticeable for larger API operations such as ElasticTranscoder's CreateJob can does about 90k bytes in 4k allocations. Whereas encoding/json marshal on the same structure only does 4k bytes in 7 allocations.
#376 updates internal/protocol/json to perform a more efficient check if a field is exported or not. Reducing the allocations caused by strings.ToLower. Several of the other protocol's marshallers perform strings.ToLower check, and probably can be updated also.

Improving the SDK's marshallers to be more efficient with allocations would help to increase performance and reduce memory usage.

[jasdel]

#404 added a nice improvement to the performance of marshalling JSONRPC, JSONUTIL, and RESTJSON protocols. With a performance improvement of about 60%. Simple structures didn't see as much impact, but more complex input structs with nested types saw larger improvements.

make bench-protocol snip:

# BenchmarkJSONRPCBuild_Simple_dynamodbPutItem:
0.9.17             50000         32969 ns/op        9757 B/op        211 allocs/op
8236f00           100000         20773 ns/op        4194 B/op        105 allocs/op

# BenchmarkJSONUtilBuild_Simple_dynamodbPutItem:
0.9.17             50000         32709 ns/op        9693 B/op        209 allocs/op
8236f00           100000         20495 ns/op        4130 B/op        103 allocs/op

# BenchmarkRESTJSONBuild_Complex_elastictranscoderCreateJobInput
0.9.17              3000        439981 ns/op       89382 B/op       2554 allocs/op
8236f00             5000        280141 ns/op       41221 B/op       1131 allocs/op

# BenchmarkRESTJSONBuild_Simple_elastictranscoderListJobsByPipeline-8
0.9.17            100000         16040 ns/op        5104 B/op         98 allocs/op
8236f00           100000         14590 ns/op        4304 B/op         80 allocs/op

[bpot]

@jasdel The interface style looks good to me.

I have one other idea. Would it be possible to hang the payload tags off of the blank identifier instead of using the unexported metadata* field/SDKShapeTraits combination? For example,

type UploadPartInput struct {
  _ struct{} `type:"structure" payload:"Body"`
  ...
}

We would still need to use FieldByName("_") to fetch the payload tag but because the field we're looking for is on the top level struct it would take the fast path instead of the path the triggers all of the allocations.

[jasdel]

Hi @bpot Thanks for digging deeper into this pattern using _ is an interesting alternative. Ill review the PR at #453 and update you there with any feedback.

[tve]

Is there any work in progress on the XML front? The EC2 DescribeImages call seems like a good test case ;-)

[jasdel]

Updated in #722. We're currently investigating how the marshalers can be improved. Hopefully this will lead to replacing the memory duplication and reflection type walking with code generation.