Introduction

If your goal is to read Excel data into a DataTable quickly in .NET, the best general-purpose answer is usually a streaming reader rather than a feature-heavy Excel manipulation library. In practice, ExcelDataReader is often the most straightforward performance-oriented choice for import scenarios. The fastest tool still depends on file format, dataset size, and whether you need formulas, styling, or only raw cell values.

What "Fastest" Usually Means Here

There are three competing goals:

• low memory usage
• low wall-clock read time
• simple conversion to DataTable

If you only need values from a worksheet, a lightweight reader is usually better than a library designed for editing, formatting, or advanced workbook features.

A Practical Default: ExcelDataReader

ExcelDataReader is popular because it can stream .xls and .xlsx content efficiently and also supports conversion to DataSet and DataTable with an extra package.

Typical package setup:

dotnet add package ExcelDataReader
dotnet add package ExcelDataReader.DataSet

For older .NET environments, you may also need to register the code pages provider.

Example: Read the First Sheet into a DataTable

Here is a minimal example.

1using System.Data;
2using System.IO;
3using ExcelDataReader;
4
5System.Text.Encoding.RegisterProvider(System.Text.CodePagesEncodingProvider.Instance);
6
7using var stream = File.Open("report.xlsx", FileMode.Open, FileAccess.Read, FileShare.ReadWrite);
8using var reader = ExcelReaderFactory.CreateReader(stream);
9
10var result = reader.AsDataSet(new ExcelDataSetConfiguration
11{
12    ConfigureDataTable = _ => new ExcelDataTableConfiguration
13    {
14        UseHeaderRow = true
15    }
16});
17
18DataTable table = result.Tables[0];
19Console.WriteLine(table.Rows.Count);

This is a strong baseline for import workloads where the output needs to become a DataTable quickly.

Why It Is Often Faster Than Richer Libraries

Libraries such as EPPlus or ClosedXML are excellent when you need workbook editing, formulas, styles, or generation. But for simple import, they often carry extra object-model overhead that you do not need.

So the tradeoff is usually:

• 'ExcelDataReader for fast ingest'
• richer libraries for more spreadsheet-aware manipulation

The fastest solution is often the one that does less.

File Format and Data Quality Matter

Performance is not only about the library. It also depends on:

• '.xls versus .xlsx'
• number of rows and columns
• merged cells and weird formatting
• header handling
• whether you need type conversion after reading

A huge sheet with messy formatting can slow down any import path, especially if you do heavy post-processing after the read.

When DataTable Itself Becomes the Bottleneck

Sometimes the real performance issue is not Excel reading. It is DataTable. DataTable is flexible, but that flexibility has overhead.

If you only need to stream rows into another system, a forward-only reader pattern may outperform loading everything into a DataTable first. But if downstream code expects a DataTable, then the conversion step is unavoidable and should be measured honestly.

Compare with EPPlus or ClosedXML Only If You Need Their Features

A richer library can still be the right choice if your import logic needs:

• formula evaluation behavior
• workbook editing before import
• style-aware reading
• tighter integration with higher-level spreadsheet concepts

In those cases, the fastest pure reader may not be the fastest end-to-end solution, because you would otherwise need a second pass or extra glue code.

Basic Benchmarking Advice

If performance matters, benchmark on representative files rather than toy spreadsheets. Compare:

• total read time
• peak memory use
• conversion time into DataTable
• post-processing cost after import

A library that wins on a 100-row file may not win on a 100,000-row workbook.

Common Pitfalls

• Choosing a rich spreadsheet library when the real job is only raw data extraction.
• Benchmarking tiny example files and assuming the result holds for production files.
• Blaming the reader library when DataTable creation is actually the slow step.
• Forgetting to register the encoding provider in environments that need it.
• Measuring only file open time instead of the full import path including type conversion.

Summary

• For fast Excel-to-DataTable imports in .NET, ExcelDataReader is often the best default choice.
• It is strong because it focuses on reading rather than full spreadsheet manipulation.
• The actual bottleneck may be DataTable creation, not just workbook parsing.
• Richer libraries are better when you need formulas, styles, or workbook editing.
• Benchmark on realistic files before declaring any library the universal fastest option.