Why do typed accessors run the process faster?

Question

Why do typed accessors run the process faster?

Asked 5 years ago

Viewed 99 times

6

I was reading an article by how to improve the performance of a Reader data using ADO.NET and in this article he cites the use of Typed Accessors to perform this function, from what I understand it has the same function as the Convert, but ends up doing the process with more speed, follows an example using the Convert:

using (SqlDataReader dr = command.ExecuteReader())
{
    while (dr.Read())
    {
          EmployeeID = Convert.ToInt32(dr["EmployeeID"]);
          LastName = Convert.ToString(dr["LastName"]);
          FirstName = Convert.ToString(dr["FirstName"]);
          city = Convert.ToString(dr["city"]);   
    }
}

Now with the Typed Accessor

using (SqlDataReader dr = command.ExecuteReader())
{
     while (dr.Read())
     {
          EmployeeID = dr.GetInt32(0);
          LastName = dr.GetString(1);
          FirstName = dr.IsDBNull(2) ? null : dr.GetString(2);
          city = dr.GetString(3);
     }
}

Why with the use of typed accessors access time to DataReader is faster? And what are in fact the typed acessors?

1 answer

Browser other questions tagged c# .net typing ado.net

You are not signed in. Login or sign up in order to post.

by Maniero • **444,682** points · Answer 1 · 2019-06-06T18:59:47+00:00

It has the opposite function of Convert. It has the function of giving you the data already with the type you need, so you do not need conversion and do not need to do this is faster. Not only that, because in some cases neither should give more performance because to deliver the data in the expected type there is an internal treatment that can be so costly when converting, but there are cases that you avoid memory allocation and double conversion, both to place the die on an object in the heap, how much to remove it from there, and this all costs, generates pressure in the Garbage Collector. The less you allocate the more you can perform.

Anyway, I thought the test was a little naive. I would do a much more extensive test to see in which situations there is loss, I don’t think it is so linear. Performance tests are not simple to do because it can have a lot of variable that interferes with the result without the person realizing.

As a matter of fact, in C# this shouldn’t even happen. This API is old and was thought at a time that C# did not have all the resources needed to handle it properly. No wonder an ORM like Dapper can do so much more robustly with the same or more performance. In the beginning C# abused the use of objects of the type object, that are always allocated in the heap and always need an extra effort to access it, since a pure object alone does not have practical functionality for the application. You have to convert it to a kind that has utility, as an integer, for example.

It also weighs a little the fact that the access in the first form is for a dictionary and not for a direct form in the structure that came from the database, this is demonstrated in the page linked in the question. But for me what matters most is that this form is not robust, rather than being slower. Not that the second way is much better, in fact it can be worse because it depends a little on how the data was requested for the database and how its structure is at that moment, so the position of the field can vary and in some cases not give error, but produce wrong results.

I am in favor of direct access to the database or the use of a Micro ORM like the Dapper. ADO.NET can be used without problems, but it is a poorly architected technology to the current standards, so when you use it, you give up having the best possible.

"Accessors" typed are access methods (methods of type get) that return an object already with a specific type, as opposed to returning a object no-brainer who needs conversion, so the object has type (technically object is a type, but not a useless for almost every use).

A few questions that will help to better understand the subject: