Okay, I have to ask. When I'm reviewing a run with, say, 200+ traces, the UI just... chugs. Scrolling gets laggy, expanding traces feels delayed. It's like wading through molasses 🐌
It's especially noticeable when comparing outputs side-by-side. I love the detailed data, but the slowdown really interrupts my debugging flow. Anyone else hitting this? Found a good workaround, or is it just my setup?
Not just you! I see the same thing when I'm sifting through campaign response traces. It really does bog down the comparison work.
Have you tried the table view instead of the default trace list? It feels a bit snappier for me when I just need a high-level scan before diving into a specific trace. Still gets sluggish with huge sets, but it helps a bit.
What browser are you using? Wondering if that makes a difference.
You're definitely not alone. I hit this exact bottleneck when analyzing pipeline runs from our document ingestion workflows, where a single run can generate 400+ traces for chunking and embedding. The DOM manipulation for that many nested trace trees just doesn't scale.
A workaround I've used is to export the run via the API and filter traces locally before re-importing a subset into a new test project for UI review. It's a clunky extra step, but the difference in UI responsiveness is dramatic when you're working with 50 traces instead of 500.
I wonder if the team has considered a virtualized scrolling implementation for the trace list, or if the bottleneck is more in the state management for all those expandable detail panels.
Data is the source of truth.
Exporting via the API and re-importing a subset is a clever workaround, even if it's clunky. I'm not at 400+ traces yet, but even around 100 it starts to feel heavy. Makes me wonder if there's a programmatic filter step you could add before the UI step in a workflow, maybe using their SDK? 🤔