ADO.NET team blog : Performance

ADO.NET Entity Framework Performance Comparison

dpblogs — Fri, 28 Mar 2008 04:43:00 GMT

There have been a few questions from the last performance blog post about how the Entity Framework compares against other object relational mapping frameworks. The simplest way to compare the performance of Entity Framework with various competing products is to use query performance against SqlClient as a benchmark. This way, anyone can run the same query benchmarks against SqlClient with your current ORM product.

Here are the last two performance blog posts:

· Exploring Performance Part 1

· Exploring Performance Part 2

Here’s the configuration that I used to run my tests:

· Visual Studio 2008.

· SQL Express (installed with Visual Studio).

· ADO.NET Entity Framework Beta 3.

· Entity Framework Tools December 2007 CTP.

· A C# console application built under the release mode configuration.

· I’m using is Northwind as my database.

· I’m running on my laptop, which is a dual core 2GHz processor with 3GB of RAM.

To create a benchmark for an ORM, we must read the data rows returned by the SqlDataReader into objects. It is not enough to simply iterate over the reader I used the same model as my previous performance blog post. Here’s the full EDM, but I really only used the Orders EntitySet.

To demonstrate performance in a slightly differently way, I added some paging queries to the scenarios from the previous posts. In the other performance blog posts, I compared tracking versus no tracking queries, and in these examples I am only showing the NoTracking cases. Objects are tracked when queried, added, or attached to the cached references inside a class owned by the ObjectContext called the ObjectStateManager. This tracking behavior is specified using the MergeOption. When updates to properties of the tracked objects occur, the properties are marked as modified and the original values are kept for performing updates back to the database. This enables users to simply write code against the objects themselves and call SaveChanges. The Entity Framework takes care of all the “heaving lift” of updating the database.

Query

For SqlClient queries, I created a class for Orders and get/set methods for properties. Here’s an example of the OrderID property. This is as simple as I can make it.

public int OrderID

{

get

{

return _OrderID;

}

set

{

_OrderID = value;

}

Here’s the SqlClient query I preformed. In the query, I specified each column individually instead using “*”. I wanted the comparison to include setting property values because that’s one of the benefits of using the Entity Framework.

SqlConnection con = new SqlConnection(connectionString);

con.Open();

SqlCommand cmd = con.CreateCommand();

string cmdText = "select CustomerID, EmployeeID, Freight, OrderDate, OrderID, RequiredDate, ShipAddress, ShipCity, ShipCountry, ShipName, ShippedDate, ShipPostalCode, ShipRegion, ShipVia from Orders order by OrderID";

cmd.CommandText = cmdText;

SqlDataReader dr = cmd.ExecuteReader();

while (dr.Read())

{

Order o = new Order();

if (!dr.IsDBNull(0)) o.CustomerID = dr.GetString(0);

if (!dr.IsDBNull(1)) o.EmployeeID = dr.GetInt32(1);

if (!dr.IsDBNull(2)) o.Freight = dr.GetDecimal(2);

if (!dr.IsDBNull(3)) o.OrderDate = dr.GetDateTime(3);

if (!dr.IsDBNull(4)) o.OrderID = dr.GetInt32(4);

if (!dr.IsDBNull(5)) o.RequiredDate = dr.GetDateTime(5);

if (!dr.IsDBNull(6)) o.ShipAddress = dr.GetString(6);

if (!dr.IsDBNull(7)) o.ShipCity = dr.GetString(7);

if (!dr.IsDBNull(8)) o.ShipCountry = dr.GetString(8);

if (!dr.IsDBNull(9)) o.ShipName = dr.GetString(9);

if (!dr.IsDBNull(10)) o.ShippedDate = dr.GetDateTime(10);

if (!dr.IsDBNull(11)) o.ShipPostalCode = dr.GetString(11);

if (!dr.IsDBNull(12)) o.ShipRegion = dr.GetString(12);

if (!dr.IsDBNull(13)) o.ShipVia = dr.GetInt32(13);

int i = o.OrderID;

}

con.Close();

When I ran this code 100 times, the average execution time was 4 milliseconds. I threw out the first run because of the one-time costs associated with connecting to the database and generating an execution plan. The first run time was 451 milliseconds.

Now moving over the Entity Framework, I performed the same query. I’m using compiled LINQ queries. Here’s the query that I performed.

public static Func<NorthwindEntities, IQueryable<Order>>

compileFullQuery = CompiledQuery.Compile(

(NorthwindEntities ne) =>

(from o in ne.Orders

select o)

);

using (NorthwindEntities ne = new NorthwindEntities())

{

foreach (Order or in compileFullQuery(ne))

{

int i = or.OrderID;

}

When I ran this compiled LINQ query 100 times, the average execution time was 7.5 milliseconds. Again, I threw out the first execution at 1782 milliseconds.

Using an Entity SQL query instead of a LINQ query, I got slightly better times. Here’s the code for the query.

using (NorthwindEntities ne = new NorthwindEntities())

{

ObjectQuery<Order> ordersQuery

= ne.CreateQuery<Order>("SELECT VALUE o FROM Orders as o");

foreach (Order or in ordersQuery.Execute(MergeOption.NoTracking))

{

int i = or.OrderID;

count++;

}

The average time after 100 runs, minus the first run, was 6 milliseconds. This time, the first execution was only 389 milliseconds. Here’s a chart that summarizes the time.

These are Beta 3 times and we are trying to make execution faster all the time. Now that we have a baseline comparison, I moved to a more common query in Web scenarios that use paging. Most folks are not going to query all the rows in a database to bind to some control, but a more realistic scenario would be to just query for a few entities at a time until all the entities are returned.

Paging Query

Paging is used to retrieve the data in chunks, such as many of us are used to when browsing for products to buy or search through the results of a Web search. For example, when I go to www.Live.com and search for “ADO.NET Entity Framework,” I may get a few million results, but I don’t want to see all those results in one web page. Instead, I get back chucks of 20 results on a page. Paging also enables me to skip to a particular page and get the result from a range of 20. In SqlClient, I can do this using the example below, where I just loop through this code for each page count and get 20 items at a time until all the 848 rows are consumed. That’s 43 queries to get all the data in more manageable pages.

SqlConnection con = new SqlConnection(connectionString);

con.Open();

SqlCommand cmd = con.CreateCommand();

string cmdText = "select TOP 20 CustomerID, EmployeeID, Freight, OrderDate, OrderID, RequiredDate, ShipAddress, ShipCity, ShipCountry, ShipName, ShippedDate, ShipPostalCode, ShipRegion, ShipVia from Orders where OrderID > @lastID order by OrderID";

cmd.CommandText = cmdText;

SqlParameter parameter = new SqlParameter("lastID", _nLastID);

cmd.Parameters.Add(parameter);

SqlDataReader dr = cmd.ExecuteReader();

while (dr.Read())

{

Order o = new Order();

if (!dr.IsDBNull(0)) o.CustomerID = dr.GetString(0);

if (!dr.IsDBNull(1)) o.EmployeeID = dr.GetInt32(1);

if (!dr.IsDBNull(2)) o.Freight = dr.GetDecimal(2);

if (!dr.IsDBNull(3)) o.OrderDate = dr.GetDateTime(3);

if (!dr.IsDBNull(4)) o.OrderID = dr.GetInt32(4);

if (!dr.IsDBNull(5)) o.RequiredDate = dr.GetDateTime(5);

if (!dr.IsDBNull(6)) o.ShipAddress = dr.GetString(6);

if (!dr.IsDBNull(7)) o.ShipCity = dr.GetString(7);

if (!dr.IsDBNull(8)) o.ShipCountry = dr.GetString(8);

if (!dr.IsDBNull(9)) o.ShipName = dr.GetString(9);

if (!dr.IsDBNull(10)) o.ShippedDate = dr.GetDateTime(10);

if (!dr.IsDBNull(11)) o.ShipPostalCode = dr.GetString(11);

if (!dr.IsDBNull(12)) o.ShipRegion = dr.GetString(12);

if (!dr.IsDBNull(13)) o.ShipVia = dr.GetInt32(13);

// just do one response to make sure we have a get

_nLastID = o.OrderID;

count++;

}

con.Close();

When I ran this loop that consumed all the data in pages of 20 rows, the time averaged 18 milliseconds on 100 tries. Each iteration made 43 paging queries to consume all 848 rows. The first run was slower at 453 milliseconds and as before, I didn’t use that number in my average calculations. This means that every paging query took less than 1 millisecond; in fact when just doing the math, the time is rounded to 0.419 milliseconds.

Now let’s see how LINQ to Entities and Entity SQL compare to SqlClient.

Here’s the paging query for LINQ to Entities, again using compiled queries. (If somehow you managed not to notice how much simpler and cleaner the LINQ code is over that SqlClient then take a moment now to enjoy this much easier way to query and materialize data.)

public static Func<NorthwindEntities, int, IQueryable<Order>>

compiledQuery = CompiledQuery.Compile(

(NorthwindEntities ne, int lastCount) =>

(from o in ne.Orders

orderby o.OrderID

select o).Skip(lastCount).Take(20)

);

using (NorthwindEntities ne = new NorthwindEntities())

{

ne.Orders.MergeOption = MergeOption.NoTracking;

foreach (Order o in compiledQuery(ne, _dbTotalRead))

{

int i = o.OrderID;

}

The time for a full read over 100 iterations averaged 87 milliseconds, ignoring the first run. This equates to an average of 2 milliseconds per query. Below is the paging query expressed in Entity SQL.

using (NorthwindEntities context = new NorthwindEntities())

{

ObjectQuery<Order> orders

= context.CreateQuery<Order>("select value o from Orders as o order

by o.OrderID skip @skip limit 20",

new ObjectParameter("skip",

_dbTotalRead));

orders.MergeOption = MergeOption.NoTracking;

foreach (Order o in orders)

{

int i = o.OrderID;

}

I ran this test 100 times; the average time was 64 milliseconds ignoring the first run. This averages about 1.5 per query, about 3 times that of SqlClient and better than LINQ to Entities.

With any framework, we need to consider the benefits and risks, and as you continue to use the Entity Framework and EDM, you’ll find it has quite a bit of benefits.

Brian Dawson
Program Manager, ADO.NET

Exploring the Performance of the ADO.NET Entity Framework – Part 2

dpblogs — Tue, 12 Feb 2008 01:04:00 GMT

Query Performance

During this post I’ll show a few patterns on how to improve the query performance.

A major design element for performance is the query cache. Once a query is executed, parts of the query are maintained in a global cache. Because of query and metadata caching, the second run always completes faster than the first run. For example, consider a query using Entity SQL query (don’t worry, we’ll discuss LINQ in just a second) with the following code.

using (PerformanceArticleContext ne = new PerformanceArticleContext())

{

ObjectQuery<Orders> orders

= ne.CreateQuery<Orders>("Select value o from Orders as o");

foreach (Orders o in orders)

{

int i = o.OrderID;

}

On the first run, the query completes in 179 milliseconds. The next time, the query completes in 15 milliseconds. The difference between the two is the cost of building the command tree that gets passed down to the provider for execution. All subsequent queries complete in or around the same time of 15 milliseconds.

LINQ Queries

LINQ queries utilize some of the same logic as Entity SQL queries, except that not all parts of the query are cached and some parts are rebuilt each time the query is executed. Take a look at the query below.

using (PerformanceArticleContext ne = new PerformanceArticleContext())

{

var orders = from order in ne.Orders

select order;

foreach (Orders o in orders)

{

int i = o.OrderID;

}

Executing this query takes 202 milliseconds on the first execution and only 18 milliseconds on subsequent executions, which is still slower than using Entity SQL. Now, let’s take a look at using compiled LINQ queries to improve performance further. The advantage of compiling a LINQ query is that the expression tree is built when the query is compiled and doesn’t need to be rebuilt on subsequent executions.

Here’s the code for a compiled LINQ query that uses a PerformanceArticleContext delegate.

public static Func<PerformanceArticleContext, IQueryable<Orders>>

compiledQuery = CompiledQuery.Compile(

(PerformanceArticleContext ne) =>

(from o in ne.Orders

select o)

);

using (PerformanceArticleContext ne = new PerformanceArticleContext())

{

foreach (Orders o in compiledQuery(ne))

{

int i = o.OrderID;

}

The times for this compiled LINQ query are 305 milliseconds on the first execution and 15 milliseconds on subsequent executions.

Here’s the standard LINQ.

using (PerformanceArticleContext ne = new PerformanceArticleContext())

{

ne.Orders.MergeOption = MergeOption.NoTracking;

var orders = from order in ne.Orders

where order.ShipCity == "London"

select order;

foreach (Orders o in orders)

{

int i = o.OrderID;

}

Now here is the compiled LINQ query.

public static Func<PerformanceArticleContext, IQueryable<Orders>>

compiledQuery = CompiledQuery.Compile(

(PerformanceArticleContext ne) =>

(from o in ne.Orders

where o.ShipCity == "London"

select o)

);

using (PerformanceArticleContext ne = new PerformanceArticleContext())

{

foreach (Orders o in compiledQuery(ne))

{

int i = o.OrderID;

}

In this query the result set is only 33 items. For the non-compiled query, the execution time is 207 milliseconds on the first execution and 17 milliseconds on subsequent executions. By comparison, the result for the compiled query is 268 milliseconds on the first execution and only 3 milliseconds on subsequent executions.

No Tracking/Tracking

In the previous examples, all the queries result in the creation of an object that gets added to the ObjectStateManager so that we can track updates. When it is not important to track updates or deletes to objects, then executing queries using the NoTracking merge option may be a better option. For example, NoTracking may be a good option in an ASP.NET web application that queries for a specific category name but doesn’t make updates to the returned data. In a case like this, there is a performance benefit to using NoTracking queries. Let’s demonstrate this by taking the same queries that we used previously and making them all into NoTracking queries. The following table demonstrates the cost of tracking objects in the query examples:

Tracking v. NoTracking on full query without parameters

Query Type	Tracking First Run (milliseconds)	Tracking Second Run (milliseconds)	NoTracking First Run (milliseconds)	NoTracking Second Run (milliseconds)
Entity SQL	179	15	149	6
LINQ	202	18	282	8
Compiled LINQ	305	15	276	6

Based on these numbers, the NoTracking option provides a big reduction in the amount of time, where most of this gain comes when we stop tracking changes and managing relationships. For a NoTracking query, the compiled LINQ query outperforms the standard LINQ query both in first execution and in subsequent executions. Note that the second execution of the compiled LINQ query is equivalent to the second execution of the Entity SQL query.

Below are the single parameter filtered queries for both tracking and no tracking.

Query Type	Tracking First Run (milliseconds)	Tracking Second Run (milliseconds)	NoTracking First Run (milliseconds)	NoTracking Second Run (milliseconds)
Entity SQL	126	3	140	2
LINQ	207	17	275	18
Compiled LINQ	268	3	277	2

Summary

When optimizing query performance in the Entity Framework, you should consider what works best for your particular programming scenario. Here are a few key takeaways:

· Initial creation of the ObjectContext includes the cost of loading and validating the metadata.

· Initial execution of any query includes the costs of building up a query cache to enable faster execution of subsequent queries.

· Compiled LINQ queries are faster than Non-compiled LINQ queries.

· Queries executed with a NoTracking merge option work well for streaming large data objects or when changes and relationships do not need to be tracked.

Brian Dawson,

Program Manager, ADO.NET

Exploring the Performance of the ADO.NET Entity Framework - Part 1

dpblogs — Mon, 04 Feb 2008 19:55:00 GMT

Performance Matters

No matter what type of application you are developing at some point in the lifecycle of a software application or service, performance matters; this is especially true when accessing data. In this article, I’m going to spend some time exploring the performance of the ADO.NET Entity Framework by breaking down the stack and showing how to speed up the simple query. I also explain the performance characteristics of the Entity Framework. I am going to run this in a two part series so keep looking back.

So we’re all on the same page, here’s the configuration that I’m using to run my tests:

· Visual Studio 2008.

· SQL Express (installed with Visual Studio).

· ADO.NET Entity Framework Beta 3.

· Entity Framework Tools December 2007 CTP.

· I work on the Entity Framework team, so I have the symbols loaded.

· A C# console application built under the release mode configuration.

· I’m using Northwind as my database.

· I’m running on my laptop, which is a dual core 2GHz processor with 3GB of RAM.

· I’m using the profile tool that ships in Visual Studio.

The General Disclaimer

Just as a disclaimer, or a thought provoking exercise, whichever is better suited for you, I want to explain why you would use the EF and Entity Data Model (EDM) and how this relates to performance. While this is an important point, I’ll point it as briefly as I can. Whenever you put a layer and reshaping model that creates a layer of abstraction or something else like an EDM to transform the relational schema of a database, there is going to be a performance decrease. Now with that said, the ADO.NET team has taken the challenge to minimize the performance decrease in this and in future releases.

Query Execution

I am using the following Northwind model as the basis for most of my exploration into performance.

Figure 1 Northwind Data model using the EDM designer

With this model I can write the following code that queries for the EntityType Order in the EntitySet Orders then iterates the returns result set.

using (NorthwindEntities ne = new NorthwindEntities())

{

foreach (Order o in ne.Orders)

{

int i = o.OrderID;

}

I ran this query through 10 iterations in my project, and iterated over a total of 848 rows of data for each query. Out of those ten iterations, here the results in milliseconds.

First run (ms)	Next 9 (ms)
4241	13	13	14	13	13	13	13	24	14

The first thing to notice is that the initial iteration takes 4241 milliseconds. The first time you create an ObjectContext and execute any operation that accesses the database, a few expensive operations occur. The pie chart below shows a breakdown, by percentage, of where the time is spent in the initial run.

Figure 2 – Code area where the first run spends execution time

Here’s what each of those sections mean.

· Loading Metadata 11% – The metadata consists of conceptual, mapping, and logical views of the data model, as defined in the CSDL, MSL, and SSDL files, respectively. During the loading of the metadata, the EDM files are loaded in the MetadataWorkspace and cached in a global cache so other workspaces can take advantage of the existing metadata.

· Initializing Metadata 14%– During the initialization of the metadata, the connection is opened and the actual metadata information is retrieved from the ADO.NET Data Provider which gets information from the database.

· Opening Connection 8%– This is simply just opening the database connection; the first time is usually the slowest.

· View Generation 56%– A big part of creating an abstracted view of the database is providing the actual view for queries and updates in the store’s native language. During this step, the store views are created. The good news is there is a way of making view generation part of the build process so that this step can be avoided at run time.

· Load Assembly 2%– The CLR types must be validated against the metadata.

· Tracking 1%– As part of the Object Services layer, there is a state manager that tracks changes made to entity objects. This is where objects are added to the state manager. Each object’s identity is created and this entity key issued to search for instances of the same entity type with the same key in the state manager. If a match is found, the merge option is used to determine the next steps.

· Materialization 7%– This is the process of actually creating the object and filling in all the properties taken from the returned DbDataReader.

· Misc 1%– This includes all of the other small operations, which includes execution of the SqlCommand, SQL Server query execution, and just application code.

When I run the EDM generator (EdmGen.exe) command line tool with the view generation command parameter (/mode:ViewGeneration), the output is a code file (either C# or Visual Basic) that I can include in my project. Having the view pre-generated reduces the startup time down to 2933 milliseconds or about a 28% decrease. For scenarios where view generation is the primary cost, such as when an object context is created for only a few queries, pre-generating these views and deploying them with your application is a good solution. However, the downside of this solution is the need to keep the generated views synchronized with changes to the model.

If we remove the cost of startup and take a look at just the cost to execute the query and return objects, here’s the breakdown of percent per operation.

Figure 3 - Warm query results

· ObjectContext construction 1.38%– This is the cost of creating the ObjectContext and looking up the existing metadata information based on the information already loaded from the first run. This is important for Web service and ASP.NET scenarios where the short lived context is the programming pattern. Because the service lives for a long time you’ll see the metadata caching and query caching significantly reduced.

· Query creation 11.02%– Each time a query is created in an ObjectContext, the Entity SQL query command is cached. This is the one-time overhead of query creation. The good news is that since query creation is cached, similar queries are executed faster. Later, I show how to use compiled LINQ queries to speed this process up even more.

· EntityKey creation 0.28%– No matter what merge option is used; there is always a cost for EntityKey creation.

· Relationship span 4.13% – For queries where the returned objects are tracked in the ObjectStateManager, we include the related ends. This is invisible to the user, except now EntityReferences have an EntityKey for relationships.

· Object lookup 1.38% – The cost of using an object’s EntityKey to determine if the object already exists in the ObjectStateManager.

· Materialization 73%– the cost of reading from the DbDataReader and creating an object.

· Misc 9.92% – Cost of the remaining stuff, including execution in SQL Server.

To better understand how the query process affects performance, here’s the basic logic of a query, in order of execution.

· Parts of the query are broken up to allow for query caching to occur resulting in a query plan.

· Query is passed through to the .NET Framework data provider and executed against the database.

· The results are returned and the user iterates over the results.

· On each entity, the key properties are used to create an EntityKey.

· If the query is a tracking query then the EntityKey is used to do identity resolution.

· If the EntityKey is not found, the object is created and the properties copied into the object.

· The object is added to the ObjectStateManager for tracking.

· If merge options are used, then the properties follow the merge option rules.

· If the object is related to other objects in the ObjectContext, then the relationships between the entities are connected.

In my next post, I’ll show some of the performance improvements that can be made on the query itself and how Entity SQL and LINQ to Entities perform.

Brian Dawson
Program Manager, ADO.NET Team

ADO.NET performance improvements with the .NET Framework 2.0 SP1

dpblogs — Tue, 29 Jan 2008 04:50:00 GMT

With the release of Visual Studio 2008 and the .NET Framework 2.0 SP1, there are some bug fixes and improvements in ADO.NET (A list of the general fixes is at http://support.microsoft.com/kb/945757)

We worked with the CLR team to get improvements like the thread pool improved scalability, and that was important for making sure our SqlReader performance is better in multithreaded scenarios (like your ASP.NET applications under load).

Particularly improved were scenarios like Data set insertion, and multi-threaded scenarios (such as ASP.NET applications) using SqlDataReader (25% better or more, depending on hardware and OS architecture).

For a complex real world web application, like Petshop, the improvement is not so big, since the application does many other things in addition to data access, but still you should get part of the benefits.

A summary of our lab numbers, just as a reference of how much improvement you can get:

Scenario	.NET FW 2.0	.NET FW 2.0 SP1	Improvement
SqlReader	14855	18100	27.3%
DataSet insert	9637	12890	40.8%
Pet Shop 4.0(Browse the store)	22.44	24.40	8.72%
Pet Shop 4.0 (Buy some pets)	21.54	23.04	6.99%

* Average throughput, over a set of runs, on 4 proc dual core servers with W2K3 SP1, 16 Gb. of RAM, with a sample average load (not by far peak capacity). Hardware differences, network conditions and the way your scenario is written affect performance, among many other things, so your mileage may vary.

You can find the code for Petshop here, and here I paste a sample of code similar to our main test loop (which is run in multiple threads, by our test harness. Remember that most SqlClient classes are not thread-safe, so your code shouldn't use the same object in two different threads):

public void SqlReader() {
    using (SqlConnection conn = new SqlConnection(_connectionString)) {
        conn.Open();
        SqlCommand cmd = new SqlCommand(_sql, conn);
        using (SqlDataReader reader = cmd.ExecuteReader()) {
            int fields = reader.FieldCount;
            while (reader.Read()) {
                for (int i = 0; i < fields; i++) {
                    object obj = reader.GetValue(i);
                }
            }
        }
    }
}

public void DataSetInsert() {
    SqlConnection conn = new SqlConnection(_connectionString);
    DataSet ds = new DataSet();
    SqlDataAdapter adp = new SqlDataAdapter(_sql, conn);
    adp.Fill(ds, "atable");
}

ADO.NET Entity Framework Beta 3 Released!

dpblogs — Wed, 05 Dec 2007 20:47:00 GMT

Announcing the release of the ADO.NET Entity Framework Beta 3!

The ADO.NET Entity Framework Beta 3 release enables users to visually design models and mappings using Visual Studio 2008 RTM and the .NET Framework 3.5 RTM. This release also incorporates fixes to bugs, performance improvements and includes many features requested by customers.

New features for the Entity Framework Beta 3 include:

Performance improvements

Much quicker object query execution
Simpler generated SQL
Faster view generation

Easier disconnected operation

Public, serializable EntityKey property on EntityReference
ApplyPropertyChanges
Attach on EntityReference
Improvements to EntityKey serialization

Extensibility and business logic enhancements

Partial methods in code generation for property changing and property changed events
Load with MergeOption

Query improvements

Additional canonical functions for LINQ to Entities
Apply operator elimination (makes more operations work in SQL Server 2000 and other databases)
Compiled LINQ query
ToTraceString() method on ObjectQuery<T> and EntityCommand to facilitate debugging

Other

Connection management refinements
Provider interface allows better reasoning about primitive types

Elisa Flasko,

Program Manager, Data Programmability

LOB Performance in SqlDataReader.

alazela — Tue, 31 Oct 2006 02:20:00 GMT

I've been answering a few questions here and there about performance for pulling LOB data out of a SqlDataReader and figured a discussion of what's going on behind the scenes may be useful. This analysis is based primarily on the number of copies and movements of data, as well as a bit of code path inspection. Since this discussion is a bit in depth, here's the quick summary of my conclusions regarding performance for LOBs on TDS connection readers, for those who'd rather not worry too much about the details.

Non-SequentialAccess least data movement: GetString/GetValue for character types, GetSqlBinary for binary types, GetSqlXml for xml. The entire LOB is in memory once (twice if you want a byte array instead of SqlBinary).

SequentialAccess least data movement: GetChars() for character types, GetBytes() for binary types. ExecuteXmlReader() for xml. The entire LOB is never forced to be in memory all at once (although you can still cause full instantiation in your own code).

On to the details! There are several different methods for pulling LOB data out, depending on the types:

GetChars(), GetString(), GetSqlChars() for character data.
GetBytes(), GetSqlBinary(), GetSqlBytes() for binary data.
GetSqlXml() for Xml data.
GetValue(), GetSqlValue() for all LOB types.

In addition using CommandBehavior.SequentialAccess can have a significant performance impact on LOBs and there are different performance implications to using the context connection vs. a standard TDS connection. I'll start with the normal (non-SequentialAccess) TDS case today.

First, packet data is read into a buffer, generally 8k in size (copy #1 of the data). This copy is in chunks, so does not From there, the LOB data is assembled into it's prefered form (string for character data, SqlBinary for binary data and a simple caching of the binary data for Xml) and stored in a row buffer. Note that this is copy #2, and all columns in the row are so copied during the Read() method.

From here, each call to obtain the data is a pretty straight-forward operation.

GetString() simply returns the string previously stored, so is very lightweight.

GetChars() converts the string to a character array (copy #3), then copies the portion of the value requested into the target buffer (copy #4). Note that if you call GetChars() with many small chunks, the first copy (#3) is cached between calls, so you only get the last copy on subsequent calls.

GetSqlChars() converts the string to character array (copy #3), wraps the result in a SqlChars object and returns it.

GetSqlBinary(), GetBytes() and GetSqlBytes() parallel GetString(), GetChars() and GetSqlChars() respectively, only using SqlBinary in place of string and byte arrays instead of character arrays.

GetSqlXml() wraps the cached binary in a stream wrapper, then wraps the stream into a SqlXml object. If you call GetReader() on the SqlXml instance, it instantiates an XmlReader directly on the wrapped stream and delivers nodes from there (copy #3, more or less). XmlReader processing isn't a simple copy of data but it should be of similar magnitude, although since it produces individual Nodes, the full LOB shouldn't need to be in memory at one time (assuming you are dropping node references once you move on to the next one).

GetValue() maps to the same process as GetString() for character types and GetBytes() for binary types (creating the byte array for you in the latter case). For xml, it is the equivalent to calling GetSqlXml(), followed by SqlXml.Value on the result. The SqlXml.Value property converts the value to a string via an XmlTextWriter, which ends up adding another data copy (#4), this one with the entire LOB in memory.

GetSqlValue() maps to GetString() for characters, GetSqlBinary() for binary and GetSqlXml() for xml.

You might note that I haven't talked about GetSqlString(). This method in all cases just wraps a SqlString object around the results of GetString(). It adds a small amount of overhead, but nothing significant to most scenarios.

So how does SequentialAccess affect things? With this option, the Read() method only processes the TDS buffer (copy #1) until the first data column is reached. At that point, control returns to the caller until one of the Get methods is called. The reader will try to fetch values directly from the TDS buffer, but isn't always able to do so. Most of the Get methods have the same code paths for SequentialAccess as they did for non-SequentialAccess, with the step of storing values in the row buffer are delayed until the Get method itself, rather than occuring in the Read() method. The exceptions are GetChars() and GetBytes().

GetChars() will copy the data from the TDS buffer to the target array. Net result is only 2 copies, both of which are chunked (small chunks copied then the buffer re-used), so the full value need never be held in memory at one time. Remember that you must get characters from the underlying value sequentially (the TDS buffer is overrwritten and the old data lost when a new packet is read). So the field offset you pass in must be after the last character read in prior GetChars() calls on the column.

GetBytes() behaves the same way, except for targetting a byte array instead of a character array.

My last note today is about xml data. Using getters, there is no way to avoid having a full copy of the data in memory at one time. However, if you use ExecuteXmlReader, the command will instantiate the reader over the incoming TDS buffers, rather than caching them. The result is three data copies (TDS buffer, byte array, xml nodes), but all are chunked.

In the end, SequentialAccess doesn't really buy you less data movement for most common scenarios, but can avoid having entire LOB in memory at one time. Don't bother using GetChars() and GetBytes() in the non-SequentialAccess case, unless it simplifies your own code -- it won't save any time (and will actually cost you a bit) in that case.

In a later blog I'll follow up with some details for readers on context connections.