improve performance of json marshalling

[fommil]

Is your feature request related to a problem? Please describe.

As detailed in the fantastic article at https://yalantis.com/blog/speed-up-json-encoding-decoding/ the default json marshaling / unmarshaling in Go uses reflection and is quite slow compared to what is possible.

It is possible to provide a custom marshaler for a type by implementing a stdlib inferface. However it is quite tedious. Thankfully, the tool ffjson does all the codegen!

Describe the solution you'd like

For the SDK to ship optimised marshallers and unmarshallers for types that are sent over JSON.

Describe alternatives you've considered

easyjson is a similar alternative if for some reason ffjson doesn't do the job. The linked article also includes a summary of other alternatives, but neither are a drop in replacement.

Additional context

The benchmark results in the article conclude

the choice of marshalling/unmarshalling method heavily depends on the type of data you’re going to work with

easyjson and ffjson offer the biggest win for "large" and "extra large" objects, and are no worse than the stdlib for small objects.

However, as with everything, it would make sense to perform some benchmarks on typical AWS data, e.g. I am particularly interested in events.KinesisEvent (link to v1 because I can't find it in v2) and everything involved in writing events out to kinesis (PutRecordsInput and its dependencies), which could make for an excellent pilot study. The true test would be if my lambda invocations get smaller as a result of using a non-reflective decoder.

[fommil]

I have been reading through the sdk code to understand how the kinesis client puts records onto a stream, and I ended up in jsonutil which seems to be an internal AWS SDK alternative to the stdlib json marshalling framework. If that's the case, then it seems like ffjson would not be an easy drop-in replacement for much of the AWS service requests.

Out of curiosity, what is the reason to have an alternative json marshalling framework just for AWS requests? Was there a limit to what the stdlib could achieve?

[skmcgrail]

jsonutil is not present in the V2 AWS SDK for Go, that is only present in the V1 SDK. For JSON based AWS protocols the SDK uses smithy-go which is a straight forward JSON writer. We use the service models to generate code that constructs the document directly using this utility. For example the PutRecordInput type serialization for JSON occurs here. For deserialization of API responses we currently use the standard libraries encoding/json decoder in combination with generated code based on service model to deserialize responses to the API modeled structures. This eliminates costly usage of tags and structure introspection that was present in the V1 SDK. Since there are now internal implementation detail and not directly exposed to users directly we can more freely change the underlying serialization or derserialization libraries we use if required to further optimize performance.

We did an extensive amount of benchmarking and optimization prior to the release of the SDK is detailed in the launch blog post here. This includes a link to the DynamoDB benchmarking program that can be used to test and review the results. V2 made significant performance improvements over the V1 SDK, and there is certainly the ability to continue to derive new improvements based on the flexibility in our design.

As a side note the V2 SDK does not currently support the event streaming protocol, which is why you were not able to find the KinesisEvent type.

With that said, I am going to move to mark this ticket for closure unless there is no further responses as it would appear this ticket was cut in haste.

[fommil]

Oh that's excellent news, thanks! I read the v2 release notes but didn't see anything about the change to the way json works, or anything about the lambda events. As an aside: I've not been able to upgrade to v2 because it is quite difficult to track down all the modules and new imports I have to use, but that's a completely separate issue to this.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[skmcgrail]

As a follow-up, there is a migration guide available for moving from V1 to V2 here. We attempted to capture the significant locations of where features were moved to as part of the broader restructure. If there is anything missing or you would like to see added to the guide that is making the migration difficult please do not hesitate to cut us an issue.

[fommil]

I see what happened re: v2, I assumed that the lambda runtime library was released in tandem with the sdk v2 and the inability to find v2 lambda stuff threw me off. I think I should have raised this ticket over at https://github.com/aws/aws-lambda-go !