Benchmarking and Performance#
These pages help you keep Cellucid responsive on large datasets, run repeatable benchmarks, and report performance issues in a way that can actually be fixed.
They are written for mixed audiences:
Wet lab / non-technical: a clear “is this normal?” checklist and safe defaults.
Computational users: scaling rules, workflow patterns, and the data characteristics that dominate performance.
Power users / developers: how to measure, compare, and debug performance issues without guesswork.
Important
Cellucid performance is usually limited by one of these three resources:
GPU-bound (rendering): too many pixels — from the window, the point size, or antialiasing — plus volumetric smoke and vector field overlays.
CPU-bound (computation): repeated filtering, heavy analysis, large category accounting.
Network/storage-bound (I/O): remote server latency, loading large expression chunks, slow disk/remote mounts.
The fastest fix is almost always: identify which one you hit first, then change the one knob that actually affects it.
Note
Two behaviours in this section are the opposite of what most people assume, and both are worth knowing before you start tuning:
Hiding cells with a filter makes navigation faster, not slower. Hidden cells are rejected before anything is drawn for them.
Each view draws every point again. On a large dataset frame time grows with the number of views, and Level of detail is what keeps a multiview comparison smooth.
Performance mental model explains both.
Fast path (if it feels slow right now)#
Use this table when you’re in the middle of work and just need relief.
What you see |
Most likely bottleneck |
Do this first (safe) |
Next page |
|---|---|---|---|
Navigation (orbit/pan/zoom) feels choppy |
GPU |
Make the window smaller, switch to Points mode, close other GPU-heavy tabs |
|
Slider scrubbing (filters) stutters |
CPU |
Turn Live filtering off and use Filter to apply once |
|
Loading takes forever or tab freezes |
I/O or memory |
Keep the file on a local disk; for a large cell-major |
|
Fans spin up / laptop throttles |
GPU + thermals |
Lower quality knobs (smoke/grid, overlays), reduce window size, clear snapshots |
|
“WebGL context lost” / blank canvas |
GPU memory |
Reload, then reduce GPU load (no smoke, no snapshots, smaller highlights, lower overlay density) |
|
“It got slower after a change” |
Regression |
Run a small benchmark loop and compare numbers |
If you suspect an environment/browser issue (not your data), also read:
Recommended reading order#
Performance mental model (learn the 3-bottleneck model once)
Performance considerations (what gets slow and why) (what actually scales with
n_cells,n_views, etc.)Large dataset best practices (how to stay fast on huge datasets)
Troubleshooting (performance) (symptom → diagnosis → fix)
If you are measuring/optimizing: Benchmarking methodology and metrics → Benchmark tools
If you’re reporting an issue: Reporting performance bugs
Pages in this section#
How to think about GPU vs CPU vs I/O bottlenecks, and how to triage quickly.
The concrete “cost model”: which interactions scale with n_cells, n_views, categories, and overlays.
A practical, step-by-step workflow for staying fast on very large datasets.
How to measure load time, FPS/latency, and memory reliably—and compare changes fairly.
How to use the in-app benchmark tools, plus interpretation and common pitfalls.
Surprising “performance cliffs” like category explosion, too many views, GPU memory limits, and huge datasets.
Symptom-based debugging for lag, freezes, context loss, and slow loads.
The benchmark panel, the historical acceptance samples, and what layout shape costs.
A copy/paste template for reporting performance issues with the right context and metrics.