[Codegen] Codegen fails to finish with many nested fragments

[pm-dev]

Summary

When running codegen on a large project with many operations with nested fragments, codegen hangs and never finishes. We were hoping the disable fragment merging feature would solve this, sadly it does not.

In an email exchange with @AnthonyMDev it sounded like this is a known issue:

This is also a known issue. It’s pretty rare, but some users with a LOT of nested fragments, we’re seeing this issue currently.

It’s due to the collections that hold all the computed merged fragment fields being so large that they are causing these issues. My current hypothesis is that the performance problem is mostly seen when the collection exceeds its capacity and is copied into a larger buffer.

I’ve been dealing with other issues, so I haven’t gotten around to this one yet, but my thought is that I can replace the array with a more suitable data structure. I think a custom tree implementation is going to be able to resolve it. Once I get the fragment merging resolved, I’ll try to work on that...

Wanted to open an issue so we can track it and prioritize it! Thanks, looking forward to finally adopting v1!

Version

1.0

Steps to reproduce the behavior

I've previously submitted a schema and .graphql operation files that allow reproducing this. Happy to send it again.

Logs

No response

Anything else?

No response

[calvincestari]

Thanks for creating the issue @pm-dev. I thought we already had an issue open for this work but I can't seem to find it so I'll add this one to the relevant milestone for tracking the work.

[pm-dev]

Any progress on this? The roadmap has said this is in progress for a while.

(in progress) Fix retain cycles and memory issues causing code generation to take very long on certain large, complex schemas with deeply nested fragment composition

[AnthonyMDev]

Well, I've made progress in the Edisonian sense. Which is to say, I've continued to rule out things that have don't solve the problem. I just recently had a meeting with another team that was exploring some possibilities for resolving this, but nothing that they have tried has worked either.

I do continue to come back to this issue as I have new ideas for things to try though.

One idea that I have is to develop some sort of short-lived SQLLite database to hold the data that is currently stored in-memory in the EntitySelectionTree and DefinitionEntityStorage. It seems like the bottleneck is likely related to the exponential growth of those data structures. This is not a small effort though, and I'm currently focusing on other projects.

As soon as I get another chance to take a crack at this, that is what I'll be exploring next.

[pm-dev]

Thanks for keeping this high priority. Considering the js version runs in about a second, do you know what the difference in algorithm is?