No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

<https://www.pulumi.com/docs/troubleshooting/|https://www.pulumi.com/docs/troubleshooting/>

Are you using the oss backends? Which provider are you using for storage if so?

it was the same when I was using <http://pulumi.com|pulumi.com> now I’m using s3

See the performance logging section there. It should definitely not happen with <http://Pulumi.com|Pulumi.com>

I can confirm that things can get slower once you have a lot of resources (I’m using Pulumi Service). One solution is to divide your code into smaller, independent pulumi projects.

I’m just interested how easy we can generate some profiling to determine where’s the bottleneck in all this.

I’m wondering if I have too many dependant outputs that’s causing the slowdown

I guess the execution must look something like this:
• download the latest state from the backend (Pulumi Service or other custom backends)
• execute all reads (either Stack References or reading existing infrastructure resources)
• calculate the diff (it should be done locally)

<@U03BBNY7KEX> are you suspecting the diff calculation takes too much time due to the number of dependencies?

do you have many Resource Output dependencies or also dependencies on other projects/stacks (stack reference)?

wait, I can have cross-stack/project dependencies? :smile:

yes <https://www.pulumi.com/docs/intro/concepts/stack/#stackreferences>

there are basically 3 types of references

Resource Output - (within stack)
Stack Reference (stack output) - another project/stack
Lookup - of existing resource

interesting, will look into it
I’m hoping to share the same k8s cluster between different stacks and deploy multiple stacks as different namespaces

take some time to play around as this decision will impact the overall architecture, I wonder if <https://archive.pulumi.com/> managed to capture one very interesting conversation where we shared different approaches