Optimizing Quantum Program Visualization

At Classiq, we provide powerful visualization capabilities for quantum programs, enabling users to clearly understand and explore the results of quantum program compilations. Recently, we encountered a challenging problem: visualizing very large quantum programs resulted in enormous JSON objects, some as large as 1.2 GB, which caused browsers to crash during parsing.

Identifying the Problem

Our visual model represents quantum program operations in a hierarchical tree structure, where each operation has multiple attributes, including nested children operations:

Operation:
 - name
 - type
 - ...
 - children: list[Operation]

For large quantum programs, this approach produced excessively large JSON payloads, leading to severe memory consumption and browser instability.

First Attempts

Initially, we experimented with encoding the data in a binary format. Unfortunately, this approach failed because the frontend still had to reconstruct and parse the entire JSON object, which was too large to manage efficiently.

Next, we considered streaming the data to the browser in smaller chunks. To achieve this, we flattened the hierarchical tree structure into a mapping from operation IDs to operations, and then streamed each operation individually. Although this approach slightly improved performance, browser memory usage remained high - between 1.5 to 3 GB, still far beyond acceptable limits.

Breakthrough: Deduplication

After discussions with colleagues from the core team, deeper research into the operation structures revealed the following insight: over 99% of the operations were duplicated. The visualization challenges stem from the fundamental nature of quantum computing, where the gate serves as the basic computational unit. Our system utilizes a confined set of 27 elementary gates (e.g., X, Y, H). Even with programs involving up to 30-40 qubits, the number of unique atomic gate operations remains below 1000. Furthermore, the qmod functions REPEAT and POWER lead to significant duplication in the compilation output. Consequently, the compilation results in a limited number of distinct operations, many of which are specific to the user's code, with the underlying operations frequently being redundant.

Leveraging this insight, we implemented a deduplication mechanism during the visual model building process. Instead of repeatedly calculating identical operations, the process now references a single instance of each unique operation, dramatically reducing the size of our visual model data.

Flat representation of the operation tree:

Operation:
 - id
 - name
 - type
 - ...
 - children_ids: list[int]

visual_model:
id_to_operations: dict[int, Operation]
main_operation_id: int

Impact of Deduplication

The improvement in memory consumption was striking. For a large circuit visual model:

Frontend Adjustments

Implementing deduplication required modifications in the frontend visualization logic. Specifically, the frontend now reconstructs the hierarchical operation tree from the flattened and deduplicated data.

Additionally, we addressed performance bottlenecks in frontend features:

• Search Optimization: Initially, the search functionality was not efficient for deeply nested structures. Now, search results are computed dynamically while reconstructing the operation tree, significantly improving user experience.
• Expand-All Feature: Optimizations here also benefited from the new deduplicated and flattened structure, enhancing responsiveness and stability.

Future Optimizations

We are considering several additional optimization strategies:

• Streaming: Once the payload grows very large, parsing becomes increasingly resource-intensive. Streaming data incrementally can help reduce the parsing overhead.
• Visualize Separately: leverages the synthesize separately feature of our synthesis process, which compiles identical circuit components only once. Using the results of synthesis, we can calculate the visualization for these recurring components just once, significantly reducing both time and memory required for calculating the visual model.
• Flatbuffers: Adopting a binary format like Flatbuffers could further reduce payload sizes, as the frontend can read directly from the binary payload without extensive parsing.
• Pagination: Introducing pagination for the operation tree would limit the amount of data processed at any given time, further enhancing frontend performance.

Lessons Learned

This experience taught valuable lessons about data structures, browser limitations, and performance optimization:

• Always examine the actual data patterns, as unexpected duplication can offer significant optimization opportunities.
• Flattening and deduplication techniques can vastly improve frontend performance for large hierarchical data.
• Collaborating closely with domain experts (like our synthesis team) can provide essential insights into optimizing software performance.

Conclusion

Through strategic analysis, collaboration, and targeted optimization, we significantly improved the visualization performance and stability of quantum circuit visualizations at Classiq. These improvements enable our users to work seamlessly with even very large quantum circuits, advancing quantum computing usability and exploration.