Sep 0.18.0 was released November 11th, 2026 adding net11.0 target with runtime-async=on, a new SIMD parser, more optimizations, several fixes incl. edge case correctness issues, see the linked release notes for more details. There have been several other minor releases since 0.12.0, these can also be checked out at releases on GitHub. Here I will take a quick look at performance progression and a fast surprise.

Sep Performance Progression (now +25 GB/s CSV parsing)

It’s a little hard to compare versions here as seen in below chart, since I have also switched CPU from 9950X to 9950X3D2, since needed to test the latter for work related ML inference. Improvements in speed are, however, generally not due to .NET JIT improvements, e.g. in .NET 11, but due to new CPU and new optimizations in Sep of which some depend on .NET 10+ features like AVX-512 VBMI2 support. As can be seen performance has improved about ~10% with some new optimizations and now hits 25 GB/s CSV parsing for the very low level CSV parsing only.

This improvement can be seen in detail below coming from a new parser (SepParserAvx512To2x256To512CmpOrMoveMaskTzcn). One that loads two Vector512<ushort> (char really) converts to two Vector256<byte> independently and then stitches them back to one Vector512<byte>. This avoids the PermuteVar8x64 otherwise used in the pure Avx512, needed due to PackUnsignedSaturate not producing a sequential result. This permute is a bit slower than doing two converts and stiching back. However, both are faster than in previous version due to the use of Avx512Vbmi2.Compress to get column separator indices. Note that this shaves off just ~3 ns per row. 3 ns!

You might also note that bytes allocated have been reduced significantly too. This is based on making parsers stateless and by making some allocations lazy so those only happen if used/needed.

Looking at performance all the way up to the actual “package assets” parsing you can see that there are minor improvements all the way up here, some of which may actually be .NET 11 improvements. In the end though shaving off 3-10 ns of actual CSV parsing compared to full asset parsing of ~400 ns per row is a minor thing.

A Fast Surprise

Now you may have noticed something in the above benchmarks comparing Sep to CsvHelper and Sylvan. CsvHelper takes a huge jump in performance going from 648.6 MB/s to 17232.1 MB/s (Row scope)! This is due to new v34 release which is a complete rewrite by Josh Close of CsvHelper. You can see more about this in the README on Github for CsvHelper. Notably CsvHelper switches to use UTF-8 as the internal storage (aka bytes) instead of chars (as is the case for Sep) and adopts SIMD optimization similar to Sep and simdjson. So if your sources/destinations better fit UTF-8 you may want to check out CsvHelper v34.

Now this is huge for the .NET ecosystem! CsvHelper has orders of magnitudes more users than Sep and a lot more features incl. now source generator based object parsing. You can see CsvHelper’s own benchmarks in the README for CsvHelper, these are different than Sep’s and are not yet updated to latest Sep version at this moment in time. In my testing and for TextReader based usage Sep is still fastest, but difference is now much smaller.

More benchmarks can be found in both Sep README and CsvHelper README. Make your own evaluation based on API, feature set and performance. Naturally, the default choice for .NET developers is CsvHelper, but Sep is a good alternative if it fits your needs.

If Sep has had just a tiny influence in the CsvHelper v34 rewrite that is probably worth more than all the Sep performance improvements combined given CsvHelper’s much larger user base and download count. I am very happy to see this and congrats to Josh Close. 🚀

That’s all! 😁