qprof

qprof: A gprof-Inspired Quantum Profiler

Background and problem

qprof is an open-source static profiler that attributes the cost of a quantum program to its routines and subroutines. It targets the familiar software-engineering problem of finding expensive parts of an implementation before deciding what to optimize. The authors adapt this problem to quantum computing, where framework-specific circuit representations, deeply nested subroutines, and repeated gate decompositions make manual resource accounting difficult. The resulting report estimates cost from an explicitly supplied gate model; it does not measure execution on a quantum processor.

The paper distinguishes developer-directed algorithmic changes from automatic compilation optimizations. Quantum compilers can simplify local gate patterns, optimize gate decompositions, or produce hardware-compatible circuits, but generally cannot identify and replace an inefficient high-level algorithm with a better one. Such a change requires the developer to understand which routines dominate the implementation and how their costs propagate through callers. Manual gate counting or theoretical analysis can become slow and error-prone when an implementation contains many nested or repeated routines.

The related work connects qprof to classical profilers, especially the call-graph reports of gprof, and to quantum resource estimators. In the framework versions discussed by the paper, Qiskit's count_ops and myQLM's Circuit.statistics provide shallow routine counts without recursively exposing the whole calling context. ScaffCC reports gate counts for individual routines but uses a restricted gate set and loses caller-callee relationships in its report. Quipper supports efficient resource estimation for very large circuits, while a Q# Trace Simulator example exports Flame graphs for a selected gate count. These approaches establish that resource estimation and hotspot analysis are existing problems. The authors' claimed novelty is a cross-framework profiling architecture that combines hierarchical calling context, configurable gate costs, and reusable output formats. These comparisons describe the software available when the paper was written.

Framework abstraction and analysis architecture

The pipeline has three separable components: framework adapters provided by the companion Python package qcw, qprof's analysis logic, and report exporters. Figure 2 depicts the conversion from a framework-specific quantum circuit through the common interface to a call graph and then to an exported report. This separation means that a newly implemented framework adapter can use existing exporters, while a new exporter can work with all implemented adapters. Plugins can be maintained outside the main qcw package, including by framework vendors.

The common abstraction is a quantum routine, defined as a named, possibly parameterized sequence of quantum subroutines. A native routine is treated as a terminal operation rather than expanded into further calls. The RoutineWrapper interface exposes a routine's name, whether it is native, and an iterator over its subroutines. It also supplies equality and hashing for reuse during analysis. The paper demonstrates direct support for Qiskit and myQLM, implements OpenQASM 2.0 input through Qiskit's translation facility, and describes an experimental XACC wrapper that exports through OpenQASM 2.0. Q# and Quipper adapters are proposed extensions rather than demonstrated implementations.

Internally, a RoutineNode represents one distinct routine and stores its self cost, accumulated subroutine cost, and an ordered list of calls to its children. A RoutineNodeFactory maintains a hash-table cache so an already analyzed routine can be reused when it appears elsewhere in the circuit. Repeated calls are still counted, but their descendant structure does not have to be reanalyzed each time. The wrappers identify routines using their names and parameters, assuming that matching names and parameters imply identical operations. The authors explicitly caution that randomized routine generation can violate this assumption.

Cost model and computational complexity

The main profile function takes a circuit, a gate_costs dictionary, an exporter, and optional framework-specific arguments. The dictionary assigns a cost to each operation that is to be treated as a terminal gate in the analysis. When an operation's name appears in this dictionary, qprof uses that supplied cost rather than continuing its decomposition. For other composite routines, it recursively accumulates the costs of child calls. Writing $S(r)$ for a routine's self cost and $C(r)$ for its total cost, the implemented aggregation can be expressed as

$$C(r) = S(r) + \sum_{s \in \operatorname{calls}(r)} C(s),$$

where the sum includes every call occurrence, including repeated calls to the same routine. Terminal operations receive their supplied self costs, while composite routines in the presented algorithm have zero self cost and inherit their costs from their descendants. The model supports additive quantities such as gate counts or sequential execution-time estimates with appropriate weights. Although the paper discusses other useful quantities, and Figure 6 illustrates a possible node containing topology and $T$-count information, the implemented algorithm computes gate cost only. Non-additive error measures, hardware topology, and parallel execution require additional analysis rather than a different label on the same sum.

The complexity analysis explains why expanded gate count alone does not determine profiling time. Under the stated assumptions on hashing and wrapper operations, each explored call-graph occurrence has constant expected processing overhead apart from visiting its children. If there are $N_u$ unique routines and each routine contains at most $N_{\mathrm{subroutine}}$ calls, the paper bounds the number of explored occurrences by $N_{\mathrm{subroutine}}N_u$. Figures 11 and 12 contrast a long chain of wrappers around a single native gate with a recursively repeated circuit containing exponentially many gate occurrences. The former still requires traversing every wrapper, while the latter can reuse previously computed subgraphs and require only linear work in the number of hierarchy levels. This benefit depends on reusable structure and suitable routine identities; it is not a general promise of sublinear analysis for arbitrary circuits.

Visual encoding and reporting workflow

qprof implements two textual exporters: a gprof-compatible report and a JSON serialization of the flattened call structure used by that exporter. The paper generates graph images by processing the gprof report with gprof2dot and Graphviz's dot tool. It presents an analysis-and-export workflow rather than a custom interactive visualization interface. Users supply the circuit and cost model, generate a report, and inspect the resulting call graph to decide which routines deserve optimization. The paper does not demonstrate interactive graph exploration, linked views, or direct circuit editing.

In these graphs, a rectangular node represents a unique routine, and a directed edge means that the source routine calls the destination routine. A node's text gives its name, its percentage of the program's total cost including descendants, its self-cost percentage in parentheses, and its total number of calls. Edges carry the percentage of total program cost attributable to that caller-callee relationship and the number of calls along it. Node color ranges from light green for low-cost routines through intermediate colors to dark red for high-cost routines. The graph aggregates repeated operations to expose software structure; unlike a conventional circuit diagram, its spatial arrangement does not encode qubit positions or the temporal ordering of every gate.

The preserved image reproduces Figure 4, a schematic illustration of a possible Grover implementation rather than a generated cost report. Separate occurrences of Hadamard gates and lower-level oracle and diffusion operations appear as separate nodes. Dashed boxes containing dots indicate repeated gates, and downward dashed arrows omit deeper decompositions for readability. Figure 5 in the paper consolidates repeated routines into shared nodes and labels edges with multiplicities, clarifying the compression principle used by the final reports. The internal representation retains ordered call occurrences even when the displayed graph consolidates them.

Figure 14 is actual generated output for the Toffoli example. The root and ccx nodes both have total cost of 100% and self cost of zero because all cost is attributed to their descendants. The dark red cx node has six calls and accounts for 98.91% of the supplied total cost, whereas the green Hadamard branch accounts for 1.09%. The zero-cost phase-gate branches reflect the chosen model's zero weight for u1; they do not establish that phase gates are free under every hardware or fault-tolerance model. The separate total and self labels let a reader distinguish an expensive native operation from a high-level routine that is expensive because of its callees.

Runtime evaluation

The runtime study profiles wave-equation, HHL, and Shor circuit families on one core of a 2.40 GHz Intel Xeon Platinum 8260M. Each profiling measurement is repeated 100 times, with the tables reporting the mean and standard deviation. The largest wave-equation instance represents 65,922,050,880 gates on 15 qubits and takes $383.65 \pm 6.79$ seconds to profile. The largest HHL instance contains 33,471,747 gates on 36 qubits and takes $98.59 \pm 0.12$ seconds, while the largest Shor instance contains 3,951,777 gates on 66 qubits and takes $0.81 \pm 0.01$ seconds. These results show that compact repetitive hierarchy can make very large represented circuits tractable to analyze, and that gate count by itself is a poor predictor of the profiler's runtime.

The timing columns require two qualifications. The myQLM wave-equation circuits are constructed lazily, so their reported profiling time includes circuit construction; Qiskit circuit-generation times are listed separately. Also, the reported cache “saved time” is estimated by recording the first profiling duration of a routine and adding that duration whenever a later call reuses its cache entry. The largest wave-equation case has an estimated saving of $270{,}824 \pm 5{,}494$ seconds, but this is not a separately measured run with caching disabled. All these values describe analysis on the authors' classical benchmark machine, not execution times on quantum hardware.

Worked examples and findings

The Toffoli example provides a small case that can be checked manually against the gate decomposition in Figure 13. The supplied weights are zero for u1, 10 for u2, 30 for u3 and u, and 300 for cx. The report in Figure 14 therefore attributes almost all cost to six controlled-$X$ operations. This demonstrates both how a gate model determines the hotspot and how routine expansion connects that hotspot to the high-level Toffoli operation.

The four-qubit Grover example searches for assignments satisfying $(q_0 \lor \neg q_1) \land (\neg q_2 \land q_3)$. Its generated graph in Figure 15 assigns 84.96% of the total cost to controlled-$X$ gates, reached through several significant parents including c3z, ccz, and mcx. The authors use the calling context to estimate the possible impact of an optimization: reducing the ccz cost by 20% would reduce the total modeled cost by about 3.72%, whereas the same relative reduction for c3z would reduce it by about 9.22%. These are arithmetic projections from the report, not measured improvements from implemented optimizations.

The myQLM quantum wave-equation example shows that the same profiling interface can analyze a different framework, with framework arguments and gate-cost definitions adapted accordingly. Figure 16 traces cost through the solver, Hamiltonian simulation, oracles, and arithmetic subroutines, showing that oracle implementations and multi-controlled-$X$ operations account for much of the modeled execution cost. To fit this graph on the page, the authors omit nodes below 0.5% of total cost and edges at or below 0.1%. It is therefore a filtered overview of the report rather than a complete rendering of every routine and call.

The evaluation establishes profiling runtimes and illustrates the reports on concrete programs. It does not report a developer user study, controlled optimization-task comparison, equivalent-task benchmark against competing profilers, or validation of predicted circuit durations through quantum-hardware executions. The evidence supports the tool's ability to expose cost structure under a chosen model; it does not measure the productivity or optimization gains that developers would obtain from using it.

Contributions, limitations, and future work

The main contribution is an extensible combination of framework abstraction, cached hierarchical cost analysis, and compatibility with established profiling-report tools. The visual contribution is a cost-annotated view of caller-callee relationships that complements gate-and-wire circuit diagrams. The paper supports this design with an algorithm description, an analysis of how hierarchy affects runtime, benchmarks on large represented circuits, and worked examples that connect cost attribution to potential optimization targets.

The method depends on meaningful routine names and preserved call structure. Figure 17 compares Shor's algorithm before and after transpilation with the paper's Qiskit version, 0.32.1, using ibm_cairo and optimization level 2. The original graph exposes several levels of routines, whereas transpilation collapses most of that hierarchy into basis operations and adds controlled-$X$ operations for the target topology. qprof can still report costs for the flattened circuit, but it cannot reconstruct the lost algorithmic calling context. This is a documented historical example of the compilation problem, not a claim about every current compiler.

The supplied gprof exporter assumes sequential execution and therefore ignores gate parallelism. The implemented model also does not distinguish the physical qubits on which a gate acts, so it cannot assign location-dependent timings or incorporate hardware placement directly. Both provided exporters require an acyclic call structure and cannot represent recursive routine calls; the paper separately claims that this exporter restriction is not inherent to qprof's core graph representation. Dynamic circuits, whose subsequent operations depend on measurement outcomes, are unsupported by the presented static analysis and wrapper interface.

The authors propose adding framework adapters and exporters such as perf_event and Flame graphs. They also discuss extending qcw to expose qubit usage and changing cost aggregation to support gate-error and topology information. An error model would still have to account for decoherence, cross-talk, and state-preparation and measurement errors before it could predict full device behavior. Support for dynamic circuits remains an additional development need. These are proposed extensions beyond the implemented additive profiling workflow.