PayloadS3Pointer inefficiently uses Jackson's ObjectMapper
Opened this issue · 0 comments
Ref:
- PayloadS3Pointer
- JsonDataConverter
- https://github.com/FasterXML/jackson-docs/wiki/Presentation:-Jackson-Performance#basics-things-you-should-do-anyway
Reuse heavy-weight objects: ObjectMapper (data-binding) and JsonFactory (streaming API)
To a lesser degree, you may also want to reuse ObjectReader and ObjectWriter instances -- this is just some icing on the cake, but they are fully thread-safe and reusable
Short version:
- PayloadS3Pointer instantiates a new JsonDataConverter for every
toJson()
invocation. - JsonDataConverter instantiates a new ObjectMapper for every invocation.
When used via a S3BackedPayloadStore in the SQS Extended Client and sending a ton of SQS messages, this can add up to quite the performance hit.
If you flipped this on its head and
- Had the PayloadStore contain an ObjectMapper
- Got rid of the
toJson()
method - Serialized the PayloadS3Pointer directly in the PayloadStore
- Probably via an abstraction containing the ObjectMapper so you could encapsulate the Exception handling nicely
- See also: https://testing.googleblog.com/2020/12/testing-on-toilet-separation-of.html
Then you could see some performance benefit by having one ObjectMapper per-PayloadStore. But, making a static, hidden, shared ObjectMapper throughout the entire library would see the biggest benefits. Again, probably contained in a Singleton wrapper class that is used and/or injected everywhere.