July 2026 Summaries

Flame charts have become generally available for all CPU profiles in Polar Signals Cloud after initially being introduced for GPU profiling, offering a temporal dimension to performance analysis that traditional flame graphs lack. While flame graphs provide an aggregated view by merging identical call chains and discarding time, flame charts preserve the original time ordering, allowing users to see when functions are executed and for how long, thus making temporal patterns like periodic spikes and scheduling behaviors visible. This capability, first validated with GPU profiling, has shown to be equally beneficial for CPU workloads by revealing distinct visual signatures in scenarios such as garbage collection pauses or lock contention that would be averaged out in flame graphs. The introduction of features like grouping by labels and zooming enhances the usability of flame charts, allowing for detailed analysis without losing context. Flame charts thus complement flame graphs, answering questions about what happened and when, and are now accessible to all users on Polar Signals Cloud with no additional configuration required.

The revamp of the profiling dashboard involved transitioning from an SVG-based renderer to a Canvas-based one, significantly enhancing performance and user experience. Previously, each frame in a flame graph was represented as a DOM node, which required the browser to manage numerous elements, resulting in slower interactions. By utilizing Canvas, the new renderer eliminates the need for these DOM nodes, instead directly painting pixels from precomputed data, which streamlines rendering and interactions like zooming, scrolling, and resetting. This shift reduces the time for rendering operations, as seen in metrics where Canvas outperforms SVG, cutting rendering times by several factors and enhancing frame rates. However, the transition to Canvas comes with trade-offs; Canvas necessitates manual handling of features like hit-testing, text truncation, and tooltip rendering that were previously managed by the DOM. Despite these challenges, the overall improvement in responsiveness and speed showcases the effectiveness of the new approach.

The blog post discusses the innovative use of Delta Lake tables and the integration of DataFusion for querying data within a Rust-based database system. The system uniquely distributes tenant data across two Delta Lake tables, requiring a process to read from both to get a comprehensive view. Initially, the custom delta-rs library fork was used for data operations, but the team explored DataFusion's capabilities to streamline this process. By building a DataFusion TableManager and the GreatLakes TableProvider, they enabled efficient parallel processing and SQL querying of the Delta Lake actions, enhancing performance. However, while DataFusion proved faster for large datasets, it incurred overhead costs that affected performance for smaller queries, such as those involving 10 commits, due to the physical planning and optimization steps. The team plans to refine this process to optimize performance further, balancing the use of DataFusion and bespoke code for varying query sizes.