Why is .NET Sql Server access faster than Excel Interop?

This might be a loaded question, and it might get voted down, but it completely frustrates me.

When you use SQL Server in your development th开发者_开发百科e data access is fast and efficient, but when you use COM to talk to Excel it is piggy slow.

It doesn't matter what data access technology you use, ADO, ADO.NET, LINQ, Entity Framework, Astoria (ADO.NET Data Services), they are all quicker than automating Excel.

If all you want is the data in cell "A1" from a Workbook, you need an Excel.Application, Excel.Workbook, Excel.Worksheet, and Excel.Range objects, just to get one data point.

WTF, Why is talking to SQL Server more efficient than talking to Excel? Excel is local and Sql Server may not be.

TIA Chris

---

Because spinning up a big monolithic executable that was designed as an interactive application is slower than talking over a fast network to an application that was designed for the purpose.

---

Every time you need to talk to excel, the server has to actually start up the excel program. It's in a hidden desktop, but it's still starting up the entire program. If you have several people using the site, that's also several instances of Excel. And if they're sharing the same workbook it's even worse.

Sql Server, on the hand, is already running. Just connect and go. It was built for this kind of thing. Excel wasn't.

---

Excel is still a com interop, even in 2007. but there is many helpers

excel-performance-new-whitepaper-available

spreadsheetgear

excelpackage.codeplex

---

This is becuase SQL server is designed to server data, Excel is not. Network latency won't even come into play here until you are retreiving 1000's maybe even millions of rows from SQL server