One run per size, so there is no variance figure here. Treat each number as a single observation, not a median. Column count moves timing more than file size does.
Methodology
Each import stage is timed separately, then the whole import is timed end to end:- File parse: time to read and parse the source CSV file.
- Validation: time to validate all rows against the target schema.
- Transformation: time to apply configured transforms to all rows.
- Destination upload: time to deliver the processed rows to the destination.
- End to end: total time from upload start to completed import.
Test environment
A mid-range consumer laptop on office Wi-Fi. The hardware is deliberately unexceptional, so these numbers read as a realistic floor rather than a best case.Importer sheet
Results
File parse
Time to read and parse the source CSV file.Validation
Time to validate all rows against the target schema.Transformation
Time to apply configured transforms to all rows.Destination upload
Time to deliver the processed rows to the destination.End to end
Total time from upload start to completed import.Reproducing the run
The sheet was configured with three columns typed Number, Email, and Date, and a single data-transform function applied tocol2. The transform is intentionally trivial: one string coercion and an uppercase. This way, the transform timings measure the pipeline’s per-row dispatch overhead, not the cost of a user’s own logic.
Data transform function
This is the exact function, applied tocol2, that produced the transformation numbers above.
Source datasets
Source CSVs carry 12 columns (Index, Customer Id, First Name, Last Name, Company, City, Country, Phone 1, Phone 2, Email, Subscription Date, Website), of which three were mapped into the sheet for the run. File sizes are decimal MB (10⁶ bytes).