Feature request: Improve cold start by optimizing imports in Powertools utilities

[ran-isenberg]

Use case

Hey,
In order to improve cold start, we are often told not to import an entire library (especially if it's large) such as 'import X' but instead import specific classes, like: 'from X import Y'.

I've noticed that some utilities dont follows this best practice:
for example

powertools-lambda-python/aws_lambda_powertools/utilities/parameters/appconfig.py

Line 11 in e29e290

import boto3

Solution/User Experience

For example: change 'import boto3' to 'from boto3 import client'

Alternative solutions

Acknowledgment

• This feature request meets Powertools for AWS Lambda (Python) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Java, TypeScript, and .NET

[leandrodamascena]

Hey @ran-isenberg! Thanks for bringing up this question. I understand you concerns here and adoption best practices, but I'm unsure if this impact coldstart because we are import boto3 and not boto3.session, for example. Let me explain my thoughts and then you let me know what you think.

Python top level imports

The way Python works, it doesn't matter if you import from boto3 or from boto3.session, it will import all top-level imports defined in the boto3 init.py file.

Making names more explicit

In this particular file, we're using boto3's session.Session, and session is a common name for libraries that can be easily confused. So we import boto3 and use boto3.session.Session to make it explicitly.

Performance test when importing boto3

I did a local performance test by importing only boto3 and importing the session directly and there is no difference. boto3 will do the same imports and will take the same time to load the objects. Obviously this can vary by milliseconds in each execution, but nothing that will impact the coldstart significance.

This is the result of using the current code:

And this is the result of using from boto3 import session:

Note that in the images the imports are exactly the same, which means that it makes no difference whether we import boto3 or from boto3 import session.

What causes an impact in this case is when we create the boto3 instance to make calls to appconfigdata, then yes it takes some time, but it is the nature of boto3 and there is not much we can do.

Please let me know if you have any other findings or tests that I can use to better understand the impact of this. I would be more than happy to reduce any impact caused by Powertools's imports.

[ran-isenberg]

Thank you for the amazing response @leandrodamascena !
I understand your response completely, so that means that boto3 is written in an unoptimized manner right? I see that the Session module has 'import boto3' so my efforts dont really matter.

That's a bummer, because in other languages it does make a difference, like in this video (I put the exact time):
https://www.youtube.com/watch?v=IHFJ-0_3cXY&t=2244s

[leandrodamascena]

Thank you for the amazing response @leandrodamascena ! I understand your response completely, so that means that boto3 is written in an unoptimized manner right?

I'm not saying that. What I'm saying is that importing the entire boto3 or boto3.session doesn't make any difference, what makes a difference is when you create boto3 instances like boto3.client("appconfigdata") because it needs to load some json files and other imports which is part of boto3 stack. I think everything can be optimized to some extent and even creating instances takes some time, boto3 is improving its performance over time.

I see that the Session module has 'import boto3' so my efforts dont really matter.

Yep, the result will be the same.

That's a bummer, because in other languages it does make a difference, like in this video (I put the exact time):
youtube.com/watch?v=IHFJ-0_3cXY&t=2244s

Even in Python, this makes a difference in some cases. For example, in Powertools, if you import just Logger(), we only import jmespath, but if you import Tracer(), we import jmespath + the AWS Xray SDK, because we need it.

This flexibility of Python allows you to optimize some areas, have more specific imports for modules and things like that.

[ran-isenberg]

fixed the link https://www.youtube.com/watch?v=IHFJ-0_3cXY&t=2244s
can you edit your response and remove the teams link ? :)

[leandrodamascena]

fixed the link youtube.com/watch?v=IHFJ-0_3cXY&t=2244s

Oh yeah, I watched that video, thanks for sharing. For example, Pydantic v2 had a significant performance regression when importing things because they were loading unnecessary stuff. I reported some data in this thread: pydantic/pydantic#6748 (comment).

They have changed a lot of things and are now more fast.

I believe this can happen in all languages, but since we are running the code inside AWS Lambda, where every ms counts and we have limited resources, we have more attention to these details.

can you edit your response and remove the teams link ? :)

Done

[leandrodamascena]

I'm closing this issue! Please feel free to reopen @ran-isenberg

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

This issue is now closed. Please be mindful that future comments 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.