SPSS Statistics ↔ Python Integration Plug-in: Where Does the Data-Materialization Bottleneck Sit When Crossing the Session Boundary?

Goal

Determine the measurable cost of moving the active dataset across the SPSS–Python boundary so that a team can decide whether to keep computation inside SPSS procedures or pull cases into Python for a given dataset shape.

Constraints and uncertainty

The integration materializes cases as Python objects (lists, tuples, or spssdata structures), so conversion time and memory scale with cases × variables. The active session state—filters, weights, case selection, variable order—controls exactly which rows cross the boundary, and the same script can return different cases on each run. Writing results back requires spss.Submit syntax, adding a second crossing. The bundled Python interpreter and the spss, spssaux, spssdata, and SpssClient module surfaces change across Statistics releases, so any measurement must be tied to the installed version. There is no documented threshold that universally favors one side of the boundary.

Questions

1. What minimal BEGIN PROGRAM PYTHON snippet reliably captures the wall-clock time and peak memory for reading the current active dataset into Python structures on this release?
2. How should the measurement account for session state (filters, weights, TEMPORARY selections) so that the observed cost reflects the actual production workload?
3. Which SPSS procedure (e.g., FREQUENCIES, MEANS, REGRESSION) provides the most representative internal-streaming baseline for comparison?