EntityModel.ConvertToOpenApi method memory usage

When using IEdmModel.ConvertToOpenApi - some EDMX documents appear to trigger massive memory usage on some occasions it never seems to finish, I've left it for upwards of 30 minutes. I am trying to generate documentation for Microsoft Dynamics Business Central API's.

Assemblies affected

This is a C# WPF .NET7.0 app

• Microsoft.OpenApi V1.6.4
• Microsoft.OpenApi.OData V1.4.0
• Microsoft.OpenApi.Readers V1.6.4

Microsoft.OpenApi.OData.EdmModelOpenApiExtensions.ConvertToOpenApi()

Steps to reproduce

the below code in conjunction with the example EDMX examples replicates the issue

var EdmData = System.IO.File.ReadAllText(ExampleEdmxFilePath);
IEdmModel model = CsdlReader.Parse(XElement.Parse(EdmData).CreateReader());
var document = EntityModel.ConvertToOpenApi();

Expected result

The OpenApiDocument is created quickly and with reasonable memory usage

Actual result

The OpenApiDocument is not created/created very slowly and uses massive amount of memory

Additional detail

From the attached zip file

• EDMX 1 - this is a collection of ~15 custom API's - the OpenApiDocument takes around 5 minutes to be created, if I export this to a json OpenApiv3 document the resulting file is 3.5Gb and it generates ~22,000 paths, it's uses ~9Gb of memory according to Visual Studio resource profiler. If I import the OpenApiV3 Json document into Swagger it is not recognised so I suspect the 3.5Gb is just hitting some form of limit.
• EDMX 2 - a separate set of 20 or so custom api's, appears to work correctly, the OpenApiDocument takes a few seconds to generate and uses very little memory
• EDMX 3 - the collection of all standard Microsoft Dynamics Business Central API V2 API's, I've never got this to finish, I've left it for over 30 minutes and it's used up to 20Gb of memory.

EDMX examples.zip

Iniziare con Microsoft.OpenApi.OData.EdmModelOpenApiExtensions.ConvertToOpenApi() e riprodurre il comportamento utilizzando gli esempi EDMX allegati e la sequenza di parsing C# nell’issue. Confrontare il modello funzionante più piccolo con EDMX 1 e EDMX 3, eseguendo al contempo il profiling dell’utilizzo della memoria e del tempo di generazione. Il lavoro è completato quando i documenti EDMX problematici producono un OpenApiDocument senza un uso eccessivo della memoria né un apparente blocco.