At my company we have a model that is a discriminated union of 8 subtypes. I sadly can not share the models or the code they depend on due to an nda. But i will try to explain my best:
Supertype: 8 Subtypes (just an interface)
Subtype1-8: They reference another subtype in at least 2 fields, most of them by collections. Some of the subtypes also reference the supertype by collections.
I have observed exponential growth in processing time, when generating a specification (with springdoc webmvc):
1 Models: 8s
2 Models: 9s
3 Models: 30s
4 Models: 187s
5 Models: 1,973s
6 Models: Didn't have the time to calculate (approx.: 18,000s / 5 hours)
(I actually thought it doesn't work for more than 3 models at first, but it was just taking a lot longer.)
The profiler analysis showed that ModelResolver.resolve() was excessively called multiple times for the same type during processing, suggesting that some form of caching could aid the processing time.
The issue happens at version 2.2.41 and 2.2.45. Interistingly version 2.2.40 directly threw a StackOverflow, this changed likely through #5004, so i guess this is somewhat related.
I am happy to help if you have further questions about the models at my company.
At my company we have a model that is a discriminated union of 8 subtypes. I sadly can not share the models or the code they depend on due to an nda. But i will try to explain my best:
Supertype: 8 Subtypes (just an interface)
Subtype1-8: They reference another subtype in at least 2 fields, most of them by collections. Some of the subtypes also reference the supertype by collections.
I have observed exponential growth in processing time, when generating a specification (with springdoc webmvc):
1 Models: 8s
2 Models: 9s
3 Models: 30s
4 Models: 187s
5 Models: 1,973s
6 Models: Didn't have the time to calculate (approx.: 18,000s / 5 hours)
(I actually thought it doesn't work for more than 3 models at first, but it was just taking a lot longer.)
The profiler analysis showed that
ModelResolver.resolve()was excessively called multiple times for the same type during processing, suggesting that some form of caching could aid the processing time.The issue happens at version
2.2.41and2.2.45. Interistingly version2.2.40directly threw a StackOverflow, this changed likely through #5004, so i guess this is somewhat related.I am happy to help if you have further questions about the models at my company.