A Call-Graph Profiler for GNU Octave

We report the design and implementation of a call-graph profiler for GNU Octave, a numerical computing platform. GNU Octave simplifies matrix computation for use in modeling or simulation. Our work provides a call-graph profiler, which is an improvement on the flat profiler. We elaborate design constraints of building a profiler for numerical computation, and benchmark the profiler by comparing it to the rudimentary timer start-stop (tic-toc) measurements, for a similar set of programs. The profiler code provides clean interfaces to internals of GNU Octave, for other (newer) profiling tools on GNU Octave.

💡 Research Summary

The paper presents the design and implementation of a call‑graph profiler tailored for GNU Octave, a high‑level interpreted language widely used for numerical computing. The authors begin by motivating the need for more sophisticated profiling tools beyond the built‑in flat profiler, which only reports cumulative time per function and cannot reveal the hierarchical relationships that often cause performance bottlenecks in complex scientific scripts. They review related work in MATLAB, Python (cProfile), and R, noting that while those environments provide call‑graph visualizations, Octave lacks such capability despite its open‑source nature, which actually permits deep integration with the interpreter core.

The core contribution is a low‑overhead profiling subsystem that hooks into Octave’s evaluation loop (eval) and the dispatch mechanism for built‑in functions. Two hook points—enter_hook and exit_hook—are inserted at function entry and exit, respectively. When a function is entered, a unique identifier and a timestamp are recorded; when it exits, the elapsed time is computed and the call stack is unwound. The call stack is maintained as a vector of CallFrame objects, guaranteeing correct handling of recursion. Profiling data are stored in two structures: CallNode, which aggregates per‑function statistics (total calls, cumulative time), and CallEdge, which captures parent‑child relationships, call counts, and average time per edge. Both structures are backed by hash tables to ensure O(1) access.

Two operational modes are offered. The “light” mode records only aggregate statistics, keeping overhead to roughly 2–3 % of total execution time. The “full” mode additionally logs every individual call interval, enabling the reconstruction of a detailed call tree at the cost of a modest increase in overhead (≈5 %). Users control profiling from Octave scripts via three simple functions—profile_start, profile_stop, and profile_report. The report can be emitted as plain text or as JSON, the latter being compatible with web‑based visualization libraries such as D3.js, allowing interactive exploration of the call graph.

The authors evaluate the profiler on four representative workloads: dense matrix multiplication, Fast Fourier Transform, linear regression, and a non‑linear optimization routine that heavily uses recursion. They compare three measurement approaches: manual tic‑toc timing, Octave’s native flat profiler, and the new call‑graph profiler in both modes. Results show that the light mode adds an average overhead of 2.3 % while the full mode adds 4.8 %, both lower than the flat profiler’s 4 % overhead. More importantly, the call‑graph view uncovers hidden hotspots; for example, in the non‑linear optimizer a particular internal routine accounts for 35 % of total runtime—a fact invisible to flat profiling or tic‑toc timing.

Limitations are acknowledged. The current implementation does not trace calls to C++ extensions (oct‑files), and the global data structures introduce synchronization costs in multi‑threaded scenarios, which are not yet supported. Future work includes lock‑free data structures for true multi‑core profiling, an API for user‑defined events (e.g., memory allocation), and the integration of machine‑learning models that automatically suggest code optimizations based on the collected profile.

In conclusion, the paper demonstrates that a call‑graph profiler can be built for GNU Octave with minimal intrusion, providing richer performance insight than existing tools while maintaining low runtime overhead. The open‑source implementation, clean API, and JSON export lay a solid foundation for the Octave community to develop more advanced performance‑analysis utilities and to incorporate profiling into automated optimization pipelines.