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 points/views, high visual quality, volumetric smoke, 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.
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 |
Switch to Points mode, clear snapshots, 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 |
Prefer Server Mode for large |
|
Fans spin up / laptop throttles |
GPU + thermals |
Lower quality knobs (smoke/grid, overlays), reduce window size, fewer views |
|
“WebGL context lost” / blank canvas |
GPU memory |
Reload, then reduce GPU load (no smoke, fewer views, 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#
01_performance_mental_model(learn the 3-bottleneck model once)02_performance_considerations_what_gets_slow_and_why(what actually scales withn_cells,n_views, etc.)03_large_dataset_best_practices(how to stay fast on huge datasets)07_troubleshooting_performance(symptom → diagnosis → fix)If you are measuring/optimizing:
04_benchmarking_methodology_and_metrics→05_benchmark_tools_if_exposedIf you’re reporting an issue:
09_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 exports.
How to measure load time, FPS/latency, and memory reliably—and compare changes fairly.
How to use in-app benchmark tools when available, plus interpretation and common pitfalls.
Surprising “performance cliffs” like category explosion, too many views, GPU memory limits, and huge exports.
Symptom-based debugging for lag, freezes, context loss, and slow loads.
Screenshot capture checklist for this section (orientation, success, common failures).
A copy/paste template for reporting performance issues with the right context and metrics.