SDK performance optimization

[ogmios-voice]

Unfortunately the code of the SDK seems to be highly unoptimized. While it's pretty stable (definitely the most important factor), a lot of code looks like to be written by juniors / inexperienced programmers: excess object creation, excess conversions (e.g. in DynamoDB), etc., all of them wasting memory and CPU, while also affecting the GC, thus the stability of the whole application. Some of them could be fixed easily, others might also need architecture redesign. (I've seen so many performance related problems in the code, that I simply cannot open a new issue for all of them.)
Of course it won't really make a difference in very poorly written applications, but I would be really interested in the memory and CPU overhead of the different projects of the SDK in stress tests, especially in case of databases.

While this is an "epic" request, involving a lot of testing and profiling, and would require a senior developer with decent experience in optimization to watch over the whole process, it would greatly improve the quality of the SDK (if the new code is also produced with these quality measures in mind).

[rdifalco]

Can you be more specific or at least point out of few specific examples? I can't imagine the AWS engineers could do anything with an issue stated so broadly without any examples of wasted memory or CPU.

[kiiadi]

@OgmiosVoice we also have aws/aws-sdk-java-v2 for Developer Preview. The new version of the SDK is focussed on flexibility, immutability and performance. We'd love to hear your feedback there.

Regarding the V1 (1.11.x) version of the SDK, if you have specific improvements you'd like to see we accept pull-requests 😄 . Although be aware that we also have a strong commitment to compile-time as well as binary compatibility.

[ogmios-voice]

@rdifalco: I didn't wanted to go into details, because based on the few times I've delved into the code of the sdk, I'm sorry to say that, but I've seen a more general lack of optimization (lack seniour code review?). But here are a few examples:

1. see Add DynamoDBMapperConfig caching #1235.
2. while this is not the best example as both scan and count should be used rarely (I'm using it for testing only), similar issues are probably present for other methods too (last checked in aws-java-sdk v1.11.155): DynamoDBMapper.count(Class<?>, DynamoDBScanExpression, DynamoDBMapperConfig) will always create a ScanRequest object from the DynamoDBScanExpression parameter. While I can create myself this ScanRequest object too, there's no DynamoDBMapper.count(Class<?>, ScanRequest) method, so I would have to duplicate the whole summarizing logic too.
   (minor issue: applyUserAgent() is called (at least) twice: 1st in createScanRequestFromExpression() then again and again within the do-while block.)
3. DynamoDB marshalling-unmarshalling: eliminate all boxing-unboxing (you have to support each primitive type as it is -- this is a huge refactoring, but that's the only serious way -- see e.g. FastUtil), reduce the number of in-middle (temporary) objects to the minimum, try to estimate the expected size of the output, allocate enough space for it -- so no resize (= allocate + copy) will occur --, and write directly into this output buffer object after object (no intermediate objects, no post concatenation, etc.).
4. still one of the first steps would be to do some benchmarking (along w/ memory usage monitoring), and profiling: that would reveal the weak links. :)

@kiiadi: I didn't know about aws-sdk-java-v2, but it sounds great. I will take a closer look when I'll have time for that. When do you expect a production ready release? What are the targeted java version for v1 and v2?
I usually prefer working on the most difficult issues (both performance- and architecture-wise), but those would more than likely involve bigger commits... Does the sdk have decent unit test coverage?

[millems]

Thanks for the detailed answer!

When do you expect a production ready release? We're not comfortable enough about our timeline to announce a date publicly yet.

What are the targeted java version for v1 and v2? 1.11.x is built on Java 1.6. 2.x is currently targeting Java 8, but we're still trying to figure out how much it would hurt adoption if we were to bump that up to Java 9. Let us know how it would affect you!

Does the sdk have decent test coverage? Eh, it's alright. In my opinion, we rely a bit too much on integration testing, and those integration tests aren't public in 1.11.x. We're leaning a bit more on unit tests for 2.x and are making our integration tests public.

Most of our own performance improvement and feature development efforts are focused on 2.0 at this time. There's definitely room for improvement in 1.11.x, but we likely won't be able to invest a large amount of time into smaller performance improvements in this version of the SDK. If there's something on the critical path that's really bugging you as a huge time-waster and should be an easy fix, we'd love to take it on. For example, Transfer Manager can be pretty inefficient at times: #1215.

For smaller improvements, we feel it's better if we direct that effort towards 2.0.

Let's close this issue for now and spin it off into separate issues for more specific improvements as we decide to make them.