RFC: Optimizing Player-UI DSL Compilation Performance

[rafbcampos]

RFC: Optimizing Player-UI DSL Compilation Performance

1. Summary

This RFC proposes targeted solutions to improve Player-UI DSL compilation performance.

Our benchmarking and analysis reveal significant performance opportunities through two distinct approaches:

• Function composition approach that delivers 31-63x performance improvements over the current React implementation.
• Custom JSX runtime with React-like API, offering 7-16x performance improvements while maintaining a familiar developer experience with minimal migration effort.

These recommendations address critical performance bottlenecks while balancing developer experience and implementation feasibility.

2. Current Challenges

2.1 Content Authoring Approaches

Player-UI currently supports two methods for content authoring:

JSON

• Direct authoring in Player-UI's transport layer
• Lightweight and fast to process
• Limited developer tooling support
• Prone to errors due to lack of type-checking
• Redundancy (lack of content reusability)

React DSL

• Rich developer tooling (type checking, syntax highlighting)
• Component reusability and familiar development patterns
• React hooks and state management
• Higher computational overhead and framework-specific coupling

The React approach relies on react-json-reconciler, which waits for all useEffect and setState updates to settle before returning results, constrained by both React APIs and JS runtime limitations.

2.2 Performance Limitations

Recent requirements to perform DSL compilation at runtime have exposed significant performance issues:

• Compilation Time: ~400ms for complex content (728KB JSON + 350KB user data)
• CPU Usage: ~200% on M3 Pro 36GB
• Service Capacity: Limited to 5 RPS on 7-unit 6GB K8s pod
• Resource Constraints: CPU exhaustion causing API gateway timeouts (5s threshold)

2.3 Root Cause Analysis

Our performance profiling identified these key bottlenecks:

React Reconciliation Overhead

• Full Virtual DOM reconciliation for every update
• Hook system processing and state management
• Unnecessary lifecycle method execution

Implementation Inefficiencies

• Sequential view processing limiting parallelization
• Lack of static content optimization

3. Proposed Solutions

3.1 Function Composition Approach

Benefits

• Purpose-built for Player-UI DSL generation
• Elimination of unnecessary framework overhead
• Direct JSON generation
• Maintains auto-documentation, IDE auto-completion, and type-safety
• Minimal runtime overhead with streamlined compilation

Drawbacks

• Migration Cost: Existing hand-authored content would need to be rewritten from React JSX to functional composition style.
• Syntax Adjustment: Developers familiar with declarative JSX syntax would need to adapt to functional composition patterns, potentially reducing initial productivity. While the functional approach maintains type safety and auto-completion benefits, it introduces a different mental model for component composition.

Performance Metrics (Average Execution Time in ms)

Content Size	FP	React	Improvement
Small	0.031	0.963	31x faster
Medium	0.074	3.573	48x faster
Large	0.136	8.638	63x faster

3.2 SolidJS Migration

Benefits

• Near-identical JSX syntax to React
• Minimal learning curve
• Could benefit from code mods in the migration path
• Built-in universal renderer support (solid-universal)
• No Virtual DOM reconciliation
• Fine-grained reactivity system

Drawbacks

• Performance Trade-off: While significantly faster than React, SolidJS is still ~4x slower than the pure functional approach for DSL compilation.
• Framework Dependency: Continues the pattern of using a UI framework as a DSL, which introduces inherent overhead even if reduced compared to React.
• Migration Effort: Requires updating component code from React patterns to SolidJS equivalents, though less effort than a complete paradigm shift.
• Partial Solution: Addresses the performance issue but doesn't solve the fundamental architectural concern of using a UI framework as a DSL compiler.
• Mental Context Switching: Developers working across different parts of the system may need to switch between React and SolidJS mental models.
• Future Flexibility: Still ties the DSL compilation to specific framework semantics, which may limit future optimization opportunities.

Migration Strategy: Partially automated using code mods for API conversion.

Performance Metrics (Average Execution Time in ms)

Content Size	Solid	React	Improvement
Small	0.129	0.963	7x faster
Medium	0.321	3.573	11x faster
Large	0.600	8.638	14x faster

3.3 Custom JSX runtime (React-like API)

Benefits

• No need for migration
• Authors don't need to learn a different DSL
• No Virtual DOM reconciliation
• Tailored to our needs

Drawbacks

• Performance Trade-off: While significantly faster than React it's still ~4x slower than the pure functional approach for DSL compilation.
• Mimicking cost: We need to guarantee API and functionality parity for the hooks we expose.

Migration Strategy: Drop-in replacement.

Performance Metrics (Average Execution Time in ms)

Content Size	Custom JSX	React	Improvement
Small	0.128	0.963	7x faster
Medium	0.299	3.573	11x faster
Large	0.539	8.638	16x faster

4. The Case for a Functional DSL Approach

While the argument that DSL should prioritize user-friendliness over performance has merit, it creates a false dichotomy that doesn't reflect our actual options. The functional approach provides both superior performance and a clear, purpose-driven developer experience that better aligns with our DSL's fundamental purpose.

We introduced React as our DSL solution when direct JSON authoring proved cumbersome, but this was a compromise born of expedience rather than optimal design. JSON was difficult to author directly, so we leveraged a familiar tool (React) as a stopgap. However, we shouldn't confuse familiarity with superiority. The React approach introduced significant overhead and dependencies, effectively asking a UI rendering library to perform a task it wasn't designed for – generating structured data.

The functional approach delivers all the benefits that initially drove us to React – strong typing, IDE auto-completion, composition patterns, and quality-of-life features like ID generation – while eliminating the unnecessary overhead of Virtual DOM reconciliation, component lifecycle management, and state handling systems that contribute nothing to our actual goal of generating Player-UI content.

The mental model of a function returning a typed object literal is fundamentally simpler and more intuitive than the current abstraction of "using React to render a specific set of non-visual components." We're actually simplifying the conceptual burden by making the DSL's purpose more transparent.

Our current React-based approach has inadvertently created a walled garden that alienates developers without React experience. The functional approach democratizes content authoring by aligning with core TypeScript patterns that any developer can quickly grasp. A function that returns a strongly-typed object is a universal pattern across programming paradigms, making our DSL more accessible to a broader range of developers.

By owning our DSL implementation rather than piggybacking on a UI framework, we gain complete control over optimization, extensibility, and evolution. We're no longer constrained by React's design decisions or update cycle. The 31-63x performance improvement isn't just a technical metric – it represents the freedom to optimize specifically for our use case rather than accepting the compromises inherent in repurposing a general UI framework.

The functional approach isn't just about performance – it's about having the right tool for the job, reducing cognitive overhead, broadening developer accessibility, and establishing a foundation that can evolve with our needs rather than being constrained by external framework decisions.

5. Recommendations

We recommend implementing the custom React-like runtime. This balanced approach offers significant performance improvements while maintaining a familiar developer experience and minimizing migration effort.

The functional programming approach remains an option for future consideration, as it provides the highest performance improvements but would require more significant changes to development patterns.

Appendix

Comparison between writing FP DSL and React DSL

Functional Programming Approach:

const ctt = collection({
  label: text({ value: b`labels.primaryInfo` }),
  template: [
    template({
      data: b`list`,
      output: "values",
      value: collection({
        values: [
          switch_({
            cases: [
              {
                case: e`${b`name.first`} == 'John'`,
                asset: text({ value: "Yay" }),
              },
              {
                case: e`${b`name.first`} == 'Jane'`,
                asset: text({ value: "Nay" }),
              },
              {
                case: true,
                asset: text({ value: "Wat" }),
              },
            ],
          }),
        ],
      }),
    }),
  ],
})(flowIdCtx);

React JSX Approach:

const ctt = (
    <Collection>
    <Collection.Label>
        <Text>{b`labels.primaryInfo`}</Text>
    </Collection.Label>
    <Collection.Values>
        <Template data={b`list`}>
        <Collection>
            <Collection.Values>
            <Switch>
                <Switch.Case exp={e`${b`name.first`} == 'John'`}>
                  <Text>Yay</Text>
                </Switch.Case>
                <Switch.Case exp={e`${b`name.first`} == 'Jane'`}>
                  <Text>Nay</Text>
                </Switch.Case>
                <Switch.Case>
                  <Text>Wat</Text>
                </Switch.Case>
            </Switch>
            </Collection.Values>
        </Collection>
        </Template>
    </Collection.Values>
    </Collection>
);