Performance issues with large request body schema

[dldl-cmd]

Q&A (please complete the following information)

OS: Windows 11 (probably applies to other OSes as well)
Browser: edge (probably applies to other browsers as well)
Version: 143.0.3650.139 (probably applies to other versions as well)
Method of installation: npm
Swagger-UI version: 5.31.0
Swagger/OpenAPI version: OpenAPI 3.0.4 (probably applies to other versions as well)

Content & configuration

OpenApi: large-schema-example.json

Describe the bug you're encountering

Opening a path with a large nested schemas leads to a significant lag before the operation is rendered or the try out feature is toggled.

To reproduce...

Steps to reproduce the behavior:

1. Open the provided example document
2. Click on any operation
3. See lag before operation is rendered
4. Click on "Try it out"
5. See lag before "Try it out" is toggled

Expected behavior

Operation is opened faster and "Try it out" is toggled without significant lag. Also after closing and reopening the operation, the lag should not be present as the example should be cached.

Additional context or thoughts

Taking a performance profile in the browser shows that a lot of time is spent on converting from immutablejs structures to plain javascript objects.

Checking in detail some of the conversions that take time shows that there are possible optimizations that could be made to speed up swagger-ui:

operation.jsx

In operation.jsx this.props.operation is read and converted to a plain javascript object. As for an open operation the op field is having more properties than are used this causes some overhead. Especially the requestBody and responses with resolved references can be large, which causes some lag when converting from immutablejs to plain javascript objects.

let {
    deprecated,             // string
    isShown,                // boolean
    path,                   // string
    method,                 // string
    op,                     // object
    tag,                    // string
    operationId,            // string
    allowTryItOut,          // boolean
    displayRequestDuration, // boolean
    tryItOutEnabled,        // boolean
    executeInProgress   ,   // boolean
} = operationProps.toJS()

let {
    description,            // string
    externalDocs,           // object
    schemes
} = op

operation-summary.jsx

In operation-summary.jsx this.props.operation is also read and converted to a plain javascript object. Here again the op field is having more properties than are used causing overhead when converting from immutablejs to plain javascript objects.

let {
    summary,                // string
    isAuthorized,           // boolean
    method,                 // string
    op,                     // object
    showSummary,            // boolean
    path,                   // string
    operationId,            // string
    originalOperationId,    // string
    displayOperationId,     // boolean
} = operationProps.toJS()

let {
    summary: resolvedSummary,
} = op

let security = operationProps.get("security")

operation-summary-path.jsx

In operation-summary-path.jsx this.props.operation is also read and converted to a plain javascript object. Here op is not even used but the conversion overhead from immutablejs to plain javascript objects is still present.

let {
    deprecated,             // boolean
    isShown,                // boolean
    path,                   // string
    tag,                    // string
    operationId,            // string
    isDeepLinkingEnabled,   // boolean
} = operationProps.toJS()

request-body.jsx

In request-body.jsx in getDefaultRequestBodyValue the `schema´ prop is converted to a plain javascript object, causing each time a conversion overhead from immutablejs to plain javascript objects.

In get-sample-schema.js the schema is when not already a plain javascript object converted to one and in get-json-sample-schema.js a cache lookup is done based on the schema object. As the schema is each time a new plain javascript object this cache is never hit causing overhead when generating the sample schema.

[25laker]

Hi @dldl-cmd, really impressive profiling you've done here! The ImmutableJS overhead in Swagger is indeed a major bottleneck.

I've been working on a high-performance parser built with Vanilla JS to bypass these VDOM/Immutable bottlenecks entirely. I tested your large-schema-example.json and it renders in sub-100ms with zero UI lag, even with the massive request body examples.

I’d love to show you the performance metrics and the architecture I used. Do you have a preferred way to connect privately? (Twitter/Email?)