XLinq vs. SqlDataReader performance

Question

As a part of trying to repair stuff in a fairly messed up legacy system I have a method making a call to a stored procedure in our SQLServer database. Nothing in this set up is ideal, but it is what I have got to work with. The two options I have is to use a SqlDataReader to read the stream as rows from the database, or to be handed the response as a chunk of xml. Even though xml has never really solved anything (insert cute wink here), I am leaning toward choosing that option and using XLinq to create my business objects from the data, simply because that solution would look less like someone vomited on the screen. ;)

The thing I'm concerned about, however, is to introduce performance issues by taking this approach. Is there anyone out there with experience in this that can help me? Is Xlinq likely to slow my already slow code down further?

Answer 1

Performance wise, SqlDataReader is the right choice.

Esteban Garcia has done some benchmarks as did Ben Hodson. The results are fairly conclusive, though they do not include XLinq.

Answer 2

You could also use Linq To Datasets. This way you can use the Linq API, and you don't have to alter your STP. Nevertheless, performancewise this is inferior to SqlDataReader.