PlotJuggler has a speed reputation — it is documented as handling thousands of timeseries and millions of data points with fast OpenGL rendering — so when a large log makes it feel slow, something specific is usually costing you, and it is worth separating what is slow before changing anything. Loading a file, holding it in memory, and interacting with its plots are three different costs. This guide gives you the checks for each, the honest limits, and the working habits that keep big recordings manageable. It is part of the Troubleshooting hub, and it invents no benchmark numbers: where figures appear below, they are the project’s own characterisations, not measurements.
Separate the three costs first
| Cost | What you experience | What drives it |
|---|---|---|
| Loading | A long wait after dropping the file, before any series appear | File size and format, how much parsing the loader must do, and how many recordings you load into one session |
| Memory | The system becomes heavy overall once the file is in | Total points held: series count × samples per series, across every loaded recording and every derived series you add |
| Interaction | Zooming, panning and scrubbing feel sluggish with the data on screen | How many curves are visible at once and how dense they are — rendering millions of points is the job OpenGL is there for, but it is not free |
Name which row you are in. A slow load will not be fixed by hiding curves, and slow interaction will not be fixed by a faster disk. The tracker shows users hitting these separately: “Loading multiple rosbags becomes progressively slower” (issue #896) is a loading-cost report, as is “Loading an overly large ulog file” (issue #1116), while “Performance loss on 3.9.0” (issue #936) is a reminder that version-to-version performance can genuinely change — one more reason the checks below start with knowing your version.
Loading checks
- Load one recording at a time. Issue #896’s title is the finding: loading additional rosbags into the same session becomes progressively slower. For big investigations, one recording per PlotJuggler instance — comparing runs in two windows — can be faster to work with than one overloaded session. Our multiple-bag comparison tutorial covers the deliberate, aligned way to compare when you do load several.
- Mind the ULog size cliff. The project’s own content-gap landscape names ULog files over 2 GB as a known hard case for this workflow. If your .ulg is in that territory, expect the load to be the expensive step, plan for it (load once, then work from a saved layout), and treat “the same file loads slowly on every machine” as information about the file, not about your install.
- Know your format’s parsing cost. A loader must parse every message it reads; structured binary recordings and text formats do not cost the same per point. If one format is consistently your bottleneck, recording or converting future captures into the format your workflow handles best is a legitimate upstream fix.
- Check the version. Performance work continues upstream — a current feature request asks for “faster, progress-reporting and truncation-tolerant ULog import” (issue #1418) — so being on a current release (PJ3 3.17.2 or PJ4 4.0.0, from the Download page) is a real check, not boilerplate.
Interaction checks: plot less, see more
Once the data is in, the cheapest performance technique is not a setting — it is restraint. PlotJuggler is built to render millions of points, but every visible curve at full density is work the GPU must repeat on every zoom and pan. Practical habits, in order of payoff:
- Plot only the series the current question needs. Thirty visible curves is a reading problem before it is a performance problem; both get better when you cut to the five that matter. Keep the rest loaded, just not drawn.
- Downsample or decimate for overview work — as a technique, honestly labelled. When you are scanning an hours-long recording for the interesting minute, a reduced-resolution copy of a series (fewer points, same shape) is the standard general technique: compute it as a derived series or produce a reduced export of the segment you care about, and return to the full-density data for the detailed inspection. This is general data-handling advice, not a hidden PlotJuggler switch — do not mistake a downsampled overview for the data itself when measuring peaks.
- Zoom before you judge performance. Interaction cost scales with what is on screen. A tool that feels heavy showing a whole flight can feel instant inside a ten-second window; evaluate responsiveness at the zoom level you actually analyse at.
- Be deliberate with derived series. Every transform, custom function and resampled curve adds points the session must hold and draw. They are worth it — that is the point of the tool — but a layout that computes a dozen derived series “just in case” is carrying weight on every interaction. Build them when the question needs them; the Lua custom functions tutorial covers building them well.
When slow is a signal, not a nuisance
If a recording that used to load comfortably suddenly does not — on the same machine and version — treat the change as data: a logger that started recording more topics, a higher sample rate, a longer capture. And if one specific file is slow everywhere while similar files are fine, suspect the file (unusually many series, an awkward structure, partial damage) before suspecting PlotJuggler; the MCAP guide covers the damaged-file branch for that format. Rule of thumb for the whole topic: PlotJuggler’s documented design centre — thousands of series, millions of points, OpenGL rendering — covers most real logs comfortably. When you are outside that centre, the fixes are workflow fixes: fewer simultaneous recordings, fewer visible curves, reduced-resolution overviews, and a current version. Those are unglamorous, and they are what actually works.
More symptoms and fixes are indexed on the Troubleshooting hub; install-side slowness and start-up problems belong to the Install guides.
Related guides on this hub: if a large recording will not load at all — rather than loading slowly — work through ROS 2 plugin not loading for ROS bags and missing data loaders explained for other formats, before returning to the performance checks above.