The lag processing stage comprises many GStreamer-based pipeline processes. As mentioned above, these pipelines are grouped into sets by configurations. The number of lag processing pipelines is specified by a configuration, and is a function of the number of different processing paths required by the lag sets being produced by the input stage under that configuration. In general, if two lag sets share the same processing steps using identical values of all the configuration parameters required to specify those steps, then those lag sets may flow into a common pipeline in the lag processing stage. As an example, this might mean that all lag sets in one spectral window can use a single lag processing stage pipeline.

The current design maintains all of the lag processing stage pipelines in (virtual) memory as long as the configuration owning those pipelines is in existence. This design could conceivably create pressures on the system address space. If that proved to be the case, pipeline processes would have to be created and destroyed as their configurations were activated and deactivated, respectively; the only significant effect on performance in that case being a longer time required to change backend configurations. Other system resources used by pipeline processes are minimal, one important reason being that no shared memory is currently employed by the GStreamer-based pipelines in the backend. If performance improvements were to require the use of shared memory, inactive pipeline processes might have to be shut down rather than being allowed to remain in memory.