wagnerblog.com

Have you ever been faced with a person who completely and utterly believes something that you know is wrong?

Recently a colleague of mine pronounced with absolute certainty that ” The item_databound event drastically slows the binding speed of a datalist control. As a matter of fact, if at all possible, you should completely avoid it if. You should never use it.” 

Whenever someone makes absolute declarations, I feel it best to test them before believing them.

So once again I pressed my trusty old Pentium 400 laptop into service. And in the same way as my previous article, I created several test pages and ran them through the Microsoft Application Test Center. The resulting matrix below, I sincerely hope, sheds some light on the impact of using the ItemDataBound event.

I wanted to create an example that mimicks some sort of manipulation at the row/field level beyond the mere act of just binding data. The examples are to bind the record but also manipulate an instance by adding a string.

The Test Pages:
All 3 pages contain identical code, except in the area of binding the one datalist that each has. For these tests, the pages were bound to 25, 50 and 100 records. Every test consisted of 100 itgerations and was executed 6 times. In order to get more accurate averages I threw out the first two times each test ran through its iterations.

Page 1 - This page uses the plain-vanilla DataBinder.Eval(Container.DataItem, “myItem”). It seems the most widely used syntax. You may even have many pages with the same syntax yourself. I assumed this page would run the fasted and made it my base line for the test.  Here is what one of the actual databinding expressions looks like
 <%# DataBinder.Eval(Container.DataItem,”OrderDate”)%>

Page 2 - This page adds the Item_Databound event and for each row that is being processed, assigns a value to a string object and renders this string as part of the datalist. The idea here is to simulate some operation on a single column of data. Again, a very common task. Of course I could have added a lot more code to this event, but I was after the unadulterated difference between a control with and one without item_databound. In a way this is supposed to show the performance impact created by simply adding this event to your control (page).

Here is the code to create the event.

public void DataList1_ItemDataBound(object sender, System.Web.UI.WebControls.DataListItemEventArgs e)
{
   System.Data.DataRowView rec = (System.Data.DataRowView) e.Item.DataItem;
   if(rec!=null) 
   {
     testStr= “Hello World”;
   }
}

On the HTML portion the change to the datalist looks like this:

<%#DataBinder.Eval(Container.DataItem, “ProductName”)+ ” ” + testStr%>

Again, just a very minimal manipulation to see how simply having this event exposed will affect the pages performance.

Page 3 - This page goes all the way by utilizing the item_databound event to bind the data to individual labels. So not only have I removed the DataBinder.Eval( ) , the code has  to now  touch many more controls inside of each row. The overall rendered size of the page will also become larger.

The DataList ItemTemplate now looked similar to this line:
<td ><asp:Label ID=”lblProductName” Runat=”server”></asp:Label></td>

And of course the item_databound had changed as well.
if(rec!=null)
{
 Label l1 = (Label)e.Item.FindControl(”lblProductName”);
 l1.Text = rec[”ProductName”].ToString();

  … other code removed for readability…
}

In all this page had 7 labels for each datarow of the list. That is a considerable impact. And of course this example is something of an extreme. I don’t think many people would go this route when using a datalist.

The Results Are In:

My test turned up one paradox. Not only does the mere exposition of the item_databound event in the code NOT slow it down at all, in two of the test cases the code ran actually slightly faster with that event exposed. Each of the 6 sub tests that make up the averages for Matrix Row No 2 and 8 were faster than the sub tests for rows 1 and 7. 

Summary:
Of course these numbers are subjective. However, in the case of my own work I frequently have to limit the number of records shown on a page to 20-25. That makes the first test case very pertinent. And in that first test case I find great comfort in knowing that the most verbose binding example (page 3) took only 19% longer than the base line (page 1), using DataBinder.Eval() . That means even if people aren’t as concerned about the minutia of databinding, for the most part ASP.NET performs well.