13  Performance and scaling

multiomeR gains performance from two complementary mechanisms: {targets} exposes independent GEM wells, modalities, and analysis branches for concurrent execution, while BPCells keeps large matrices on disk and streams many operations instead of materializing dense objects.

Actual wall time depends on input nuclei, retained cells, peak counts, enabled plots and modules, hardware, scheduler latency, controller concurrency, and which targets are already up to date. Treat benchmark results as workload descriptions, not promises for another machine or configuration.

13.1 Recorded examples

The recorded benchmark below contains two public aggregations and estimates the critical path to each final multimodal_Seurat_object from recorded {targets} runtime metadata.

Aggregation	GEM wells	Cell Ranger input nuclei	Estimated critical path	Sum if ancestor targets ran serially
immune_human_2x	2	17,277	17.3 minutes	31.4 minutes
PBMC_human_6x	6	51,291	23.8 minutes	52.4 minutes

The critical path is the longest chain of dependent tasks: it estimates the fastest completion if enough workers are available. This estimate treats dynamic branches as concurrently runnable. The difference between that estimate and the serial sum illustrates available parallelism for these two runs; it does not establish a general scaling law from two observations.

13.2 How to use these numbers

• Compare changes only when the pipeline version, configuration, target endpoint, and estimation method are recorded together.
• Expect scheduler queue time and limited worker capacity to increase observed wall time beyond the graph-only critical-path estimate.
• Inspect target-level runtime and memory on your own representative aggregation before sizing a production run.
• Start with one aggregation and a selected result, then increase worker concurrency only when memory headroom is known.

Configure execution capacity in Distributed computing. If a run is unexpectedly slow or repeatedly rebuilds targets, use Troubleshooting.