Fix: Slow Import Time in stripe-python

Out of curiosity what serverless platform are you deploying to? This would only be an issue on cold starts, is that correct?

For production, yes, it's mostly an issue with cold starts. If you use python's `importtime` you can see Stripe takes up a big, big chunk. See more here: https://adamj.eu/tech/2023/03/02/django-profile-and-improve-import-time/ Cold start platforms: Google Cloud Run in my case. But it also has local dev implications. Django and FastAPI rely on an autoreloading server. Unlike frontend tools like vite, there's no concept of hot module reloading. So this library — with no usage, just importing — is responsible for a 500ms lag in restarts. Imagine a few other libraries like this (Google storage does the same thing), and it starts to add up.

Thanks for reporting this. We will be looking into SDK optimizations in the new year.

+

I noticed that that ram usage has crept up to very high levels with just `import stripe` - 4.2.0 - 11mb - 7.14.0 - 28mb - 11.5.0 - 57mb I tested with Docker python:3.13 image. I ran pip install stripe==version. Run python. Measure process memory. Run `import stripe`. Measure again and take the difference. I discovered this by noticing a major memory usage regression in my web application, which is attributed to upgrading stripe. This is likely the same issue, though I'd argue the memory usage is just as bad or worse as the slow start time. For comparison, my entire Celery process is only 80mb, this increase was enough to halt release and investigate for me.

I took a peek with memray. I see that it imports both aiohttp and requests, lovely. Those were installed in my testing environment. _test_helpers_service looks questionable for importing. https://gitlab.com/-/snippets/4802529

Some of the import time regression could be inside requests itself, depending on which version of requests you're getting with the different versions of stripe you tested: https://github.com/psf/requests/issues/6790

I had to increase the capacity of my Fargate ECS service after adding this SDK to my project. Some optimizations would be much appreciated.

Can confirm the memory usage has been an issue for us as well. We ended up refactoring out the stripe-python sdk. Claude makes short work out of building your own stripe.construct_event() method, dropped 50mb per worker from our memory use.

@chris-mui could you elaborate on this? Do you mean still installing the library and going more low level? Or just actual API requests directly?

Completely removed stripe sdk. Copy pasted api spec into claude to build out pydantic models for handling the requests. Construct_event() which handles webhook signature verification built in a similar fashion (didn't need any context to build this one though).

Just upgraded Stripe from a very old version to the latest, and memory usage also peaked. If someone could share a working solution to import on demand, that would be nice!

@ludo-idemenager I have a file named `slow.py` In it: ```python from __future__ import annotations from typing import TYPE_CHECKING, Protocol, Type from django.conf import settings if TYPE_CHECKING: import stripe class StripeTestHelpers(Protocol): TestClock: Type[stripe.test_helpers.TestClock] class StripeBilling(Protocol): Session: Type[stripe.billing_portal.Session] class StripeModule(Protocol): billing_portal: StripeBilling test_helpers: StripeTestHelpers Customer: Type[stripe.Customer] Invoice: Type[stripe.Invoice] CardError: Type[stripe.CardError] InvalidRequestError: Type[stripe.InvalidRequestError] AuthenticationError: Type[stripe.AuthenticationError] APIConnectionError: Type[stripe.APIConnectionError] StripeError: Type[stripe.StripeError] Subscription: Type[stripe.Subscription] Token: Type[stripe.Token] Price: Type[stripe.Price] BalanceTransaction: Type[stripe.BalanceTransaction] PaymentMethod: Type[stripe.PaymentMethod] def get_stripe_client() -> StripeModule: import stripe stripe.api_key = settings.STRIPE_SECRET_KEY stripe.api_version = "2019-12-03" return stripe ``` Those are all the typings I need, otherwise they are broken as `mypy` has no way to just re-export all the types of a module unchanged. Then in my code: ```python def create_subscription( request: Request, form: forms.CreateSubscriptionForm ) -> SomeReturnType: stripe = slow.get_stripe_client() ```

Thanks, that's what I ended up doing too! > [@ludo-idemenager](https://github.com/ludo-idemenager) > > I have a file named `slow.py` > > In it: > > from __future__ import annotations > > from typing import TYPE_CHECKING, Protocol, Type > > from django.conf import settings > > if TYPE_CHECKING: > import stripe > > > class StripeTestHelpers(Protocol): > TestClock: Type[stripe.test_helpers.TestClock] > > > class StripeBilling(Protocol): > Session: Type[stripe.billing_portal.Session] > > > class StripeModule(Protocol): > billing_portal: StripeBilling > test_helpers: StripeTestHelpers > Customer: Type[stripe.Customer] > Invoice: Type[stripe.Invoice] > CardError: Type[stripe.CardError] > InvalidRequestError: Type[stripe.InvalidRequestError] > AuthenticationError: Type[stripe.AuthenticationError] > APIConnectionError: Type[stripe.APIConnectionError] > StripeError: Type[stripe.StripeError] > Subscription: Type[stripe.Subscription] > Token: Type[stripe.Token] > Price: Type[stripe.Price] > BalanceTransaction: Type[stripe.BalanceTransaction] > PaymentMethod: Type[stripe.PaymentMethod] > > > def get_stripe_client() -> StripeModule: > import stripe > > stripe.api_key = settings.STRIPE_SECRET_KEY > stripe.api_version = "2019-12-03" > return stripe > Those are all the typings I need, otherwise they are broken as `mypy` has no way to just re-export all the types of a module unchanged. > > Then in my code: > > def create_subscription( > request: Request, form: forms.CreateSubscriptionForm > ) -> SomeReturnType: > stripe = slow.get_stripe_client()

Over 50% of start time for our app is by the stripe SDK, and like others have observed, RAM usage has crept up as the library version has matured

Upgraded from an old version and got a major increase of memory usage. Tried several versions from major 9 to 12. None seemed to be fixed. When can a fixed version be expected?

I can add that on AWS Lambda with python3.10 I'm sometimes seeing 3 second imports 😱

The size of this library and its memory demands are a big problem for my project. I have relatively simple needs at the moment, and am stuck using v6.0.0, which has a disk footprint of 900KB. Sadly, v12.3.0 has a disk footprint of 15MB+. With respect, that size is out of control. Why do I care? I, too, run in a "serverless" environment (Google App Engine). I'm less concerned about startup time than I am about absolute storage needs. I would have to increase the instance machine class (at significant expense) to be able to handle this library, which is rarely used. I really don't understand why the library needs to be so large... presumably the complexity could be/should be handled at Stripe's servers. At a minimum, perhaps we could have different versions or complementary Stripe modules so we don't need such a large footprint. Or maybe a REST API so we don't need any of your software.

Maybe somone at Stripe can spend some time to investigate the performance problems, @ramya-stripe?

> Maybe somone at Stripe can spend some time to investigate the performance problems, [@ramya-stripe](https://github.com/ramya-stripe)? Incredibly overdue, this SDK is really beginning to feel like bloatware at this point. Adding payments to an app shouldn't require suffering to performance issues