Benchmarks

CsvHelper against Sep 0.17.1 and Sylvan.Data.Csv 1.4.4, measured with BenchmarkDotNet 0.15.8 on .NET 10.0.12, Windows 11, AMD Ryzen 9 9950X3D (one core, AVX-512). Times are means per operation; lower is better. Sep is the baseline. CsvHelper runs with its default options, except where a row says otherwise.

Data sets (deterministic, generated by DataGenerator, 50,000 records each):

• PackageAssets (16 MB, LF): 25 short text columns modelled on the NuGet package assets data set; one column is quoted.
• Floats (14.7 MB, LF): 3 text columns and 25 float columns, like a machine learning feature file.
• Quoted (7.1 MB, CRLF): 7 columns; the 4 text columns are quoted and contain separators, escaped quotes and line breaks.

Scenarios: Rows finds the records only. Cols touches every field as a span, without creating strings. Records builds an object with 25 string properties per record and keeps them all. Strings creates a string for every field. Floats parses the 25 floats of each record and sums them. Write writes the same records, and every library produces byte-identical RFC 4180 output. Reads come from a MemoryStream unless the data column says otherwise. The Async variants use each library's async API.

Reading

Writing

¹ Sep with its per-column string pool (SepToString.PoolPerCol()), CsvHelper with PoolStrings = true.

² Objects of a [CsvRecord] type with 25 string fields: CsvHelper's WriteRecords with its generated record writer, which is 2% slower than writing the fields by hand (8.48 ms). Sep and Sylvan do not write objects.

Throughput: CsvHelper finds records at 8.0 GB/s (Sep 5.7 GB/s) and reads every field of PackageAssets at 5.3 GB/s (Sep 4.3 GB/s). It writes 1.9 GB/s of text records (Sep 0.58 GB/s) and 0.62 GB/s of floats (Sep 0.17 GB/s).

Records keeps 1.25 million strings in memory (62 MB allocated per run, the same for every library), so garbage collection takes most of its time, and the libraries end up close. Pooling strings (PoolStrings = true) cuts that to 18.4 MB (Sep's pool: 28.4 MB). It is off by default because for strings that are used and dropped (Strings) a pool lookup costs more than it saves. The writer allocates under 400 bytes per run (Sep 7–10 KB).

How the comparison is kept fair:

• All three libraries return the same data: the same record count and content hash, the same sum of floats, byte-identical written files (in the PackageAssets Cols scenarios Sep's total is larger because its spans keep the quotes, see below). dotnet run -c Release -- verify runs each benchmark once and prints these values.
• Sep reads with Unescape = true in the Records and Strings scenarios and on the Quoted data, so every library returns the same unquoted values. In the PackageAssets Rows and Cols scenarios it uses its defaults, so in Cols its spans of the one quoted column still include the quotes, which is slightly less work. Sep writes with Escape = true, Sylvan with \r\n line endings.
• File scenarios use each library's own file API (Sep.Reader().FromFile/FromFileAsync, Sylvan's Create/CreateAsync with a path, CsvReader.FromFile).
• The job pins the process to one performance core. It sets DOTNET_TC_CallCountingDelayMs=0 so that benchmarks taking a long time per call reach optimized (Tier-1) code before measurement, which applies to every library alike.

Other parsing modes

The parsing modes other than RFC 4180, on the PackageAssets records (50,000, 25 columns), on the same machine. Sep has no escape mode, and none of the other libraries reads or writes fixed widths, so each row names its own baseline.

• Escape (16.1 MB): a backslash before every comma and backslash (framework monikers, Windows paths), nothing quoted. Sylvan with CsvStyle.Escaped.
• NoEscape (16.0 MB): tab separated, nothing quoted or escaped. Sep with DisableQuotesParsing; Sylvan reads it in its standard mode.
• FixedWidth (29.0 MB): every column padded with spaces to its longest value. The baseline is the usual hand-written loop: StreamReader.ReadLine, then a trimmed slice per column (Substring for records), and PadRight per value for writing.

Every library returns the same results here too, and every writer produces byte-identical output.

Separators of several characters

The PackageAssets and Quoted data with || in place of every comma (in the Quoted data, the commas inside quoted fields become || too), read through CsvSeparatorStream. Sep and Sylvan do not read such separators. The baseline is CsvHelper on the same data with commas, so the difference is the cost of the stream.

The stream alone replaces separators at 9.6 GB/s on PackageAssets and 6.9 GB/s on the Quoted data with AVX-512 VBMI2 (one VPCOMPRESSB per 64-byte block), and at 5.8 and 4.6 GB/s with the code for AVX2 and SSSE3 on the same machine (a byte shuffle per 8 bytes, which for a separator of two bytes also writes the replacement). It allocates about 300 bytes per stream.

Dynamic records

The PackageAssets data read as dynamic records, without a record type (see Dynamic records). Dynamic reads 3 of the 25 fields of every record by name (record.Id, record.Version, record.FileName); DynamicToList keeps every record in a list. They are compared with the usual way to get dynamic records: an ExpandoObject per record, with a string per field added by header name (filled by CsvHelper's reader, so the difference is the record).

CsvHelper reads dynamic records at 3.2 GB/s (4.1 GB/s from a byte[]). It allocates 29.7 MB per run in Dynamic (14.3 MB from a byte[], whose records reference the input in place; most of the rest are the 150,000 strings of the fields read), against 136 MB for the ExpandoObjects. Kept in a list, its 50,000 records take 23.6 MB and the ExpandoObjects 137 MB. The ExpandoObject times vary more than CsvHelper's (a standard deviation of 9 ms in Dynamic).

Writing on several threads

ParallelWriteRecords against WriteRecords on the same [CsvRecord] objects (see Writing from several threads), with byte-identical output. Unlike the other benchmarks, these run on all 32 threads of the same machine (16 cores). The data are the PackageAssets records, the Floats records (objects with 25 float fields) and Orders (9.5 MB): 12 fields of dates, a decimal, a Guid, numbers and text. 50,000 records each. The 4, 8 and 16 thread columns set maxDegreeOfParallelism; 32 threads is the default, one per processor.

To a file (CsvWriter.ToFile, on a WD Blue SN5000 NVMe drive), with 32 threads:

To memory, the parallel writer reaches 12.1 GB/s on PackageAssets, 9.1 GB/s on Floats and 11.3 GB/s on Orders. To a file, all three end up at 2.7 to 2.9 GB/s: writing the file is then the limit, so the records that cost the most to format gain the most. A call allocates about 42 KB with 32 workers (their writers and output buffers), against 416 bytes for WriteRecords.

Run them with:

cd bench/CsvHelper.Benchmarks
dotnet run -c Release -- --filter *PackageAssetsRead.* *PackageAssetsReadFromString.* *PackageAssetsReadFile.* *FloatsRead.* *QuotedRead.* *PackageAssetsWrite.* *FloatsWrite.* *QuotedWrite.*
dotnet run -c Release -- --filter *.EscapeRead.* *.NoEscapeRead.* *.FixedWidthRead.* *.EscapeWrite.* *.NoEscapeWrite.* *.FixedWidthWrite.*
dotnet run -c Release -- --filter *SeparatorPackageAssetsRead.* *SeparatorQuotedRead.* --anyCategories Rows Strings
dotnet run -c Release -- --filter *ParallelWrite.*            # on every core

dotnet run -c Release -- verify                # check that all libraries return the same results

dotnet run -c Release -- quick QuotedRead      # quick Stopwatch runner for tuning (not for published numbers)