RedocStandalone performance issue on many circular reference

[Minh-Trieu]

Describe the bug
RedocStandalone have performance issue when rendering a contract with a lot of circular reference. It use a lot of memory (more than 1gb) and can often end to a browser page crash.

Issue faced on redoc@2.2.0.

Expected behavior
Be able to render the contract with reasonable performance/memory consumption.

Screenshots
Using https://redocly.github.io/redoc/ show the same behaviour

Additional context
Example file that reproduce the behaviour
circular_reference.txt

I also tried to to bundle deferenced with redoc cli but the generated contract was not able to be rendered by RedocStandalone.

[SpeckiJ]

I have the same issue with a rather complex and deeply nested schema with many allOfs and have debugged a bit further:

The Memory/CPU usage is caused by the circular-dependency-detection allocating and deallocating massive amounts of strings here:

redoc/src/services/OpenAPIParser.ts

Line 19 in 639fd2c

return stack ? base.concat(stack) : base;

--> concat creates a completely new array and copies all elements over, the old elements are then garbage-collected. In my case this doubles the size of the array each time (it is concatenating itself to itself), and the function is called several hundred thousand times, it very very quickly eats up Gigabytes of memory and the Browser gets overwhelmed with garbage-collection.

this function is called unconditionally once per deref-call:

redoc/src/services/OpenAPIParser.ts

Line 94 in 639fd2c

baseRefsStack = concatRefStacks(baseRefsStack, objRefsStack);

possibly even a second time if the current object is not actually a reference:

redoc/src/services/OpenAPIParser.ts

Line 123 in 639fd2c

refsStack: concatRefStacks(baseRefsStack, objRefsStack),

When commenting out the concat my schema (as well as the one provided above) loads in seconds, compared to crashing the browser after eating all the RAM. There is an ominous MAX_DEREF_DEPTH flag, but it is only checked later in the logic after the stacks have already been concatted, and only in the special case that an actual #ref was present, so it does not work as a protection here and the ref-stack just freely grows to millions of strings.

@RomanHotsiy @AlexVarchuk I would be open to refactor this to be more sane and submit a PR (first proposal would be to use a Set<string> for tracking refs), but I am having trouble understanding whether this whole refsStack-ordeal is really just there for circular dependency detection or if it fulfills another purpose that i cannot see currently?