Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PayloadS3Pointer inefficiently uses Jackson's ObjectMapper #51

Open
Logic-32 opened this issue Dec 1, 2023 · 0 comments
Open

PayloadS3Pointer inefficiently uses Jackson's ObjectMapper #51

Logic-32 opened this issue Dec 1, 2023 · 0 comments

Comments

@Logic-32
Copy link

Logic-32 commented Dec 1, 2023

Ref:

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:

  1. PayloadS3Pointer instantiates a new JsonDataConverter for every toJson() invocation.
  2. 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

  1. Had the PayloadStore contain an ObjectMapper
  2. Got rid of the toJson() method
  3. Serialized the PayloadS3Pointer directly in the PayloadStore

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant