ASP.NET Data Binding Performance – Collection Is More Expensive Than Datatable

    In my previous post -  Best ASP.NET Performance Winner For Data Binding - Hands Up To Response.Write() – I’ve conducted several simple performance tests for data binding to GridView in ASP.NET page. What surprised me most is that eliminating massive loops and collection enumerations did not help in reducing CPU utilization. When we measured the execution times for both scenarios, DataBind() method revealed the secret.

Reporting Execution Times

We used System.Diagnostics.Trace to report execution times.

UseCustomCollection.aspx.cs

    1: System.Diagnostics.Trace.WriteLine("1. STARTING");

    2:  

    3: DataGrid datagrid = SampleServices.GenerateDynamicDataGridControl();

    4: this.Controls.Add(datagrid);

    5:  

    6: System.Diagnostics.Trace.WriteLine("2. GRID CREATED AND ADDED TO PAGE");

    7:  

    8: MyCollection myCollection = (MyCollection)SampleServices.GenerateCollection(200);

    9:  

   10: System.Diagnostics.Trace.WriteLine("3. CUSTOM COLLECTION CREATED");

   11:  

   12: datagrid.DataSource = myCollection;

   13: datagrid.DataBind();

   14:  

   15: System.Diagnostics.Trace.WriteLine("5. DONE");

UseDataTable.aspx.cs

    1: System.Diagnostics.Trace.WriteLine("1. STARTING");

    2:  

    3: DataGrid datagrid = SampleServices.GenerateDynamicDataGridControl();

    4: this.Controls.Add(datagrid);

    5:  

    6: System.Diagnostics.Trace.WriteLine("2. GRID CREATED AND ADDED TO PAGE");

    7:  

    8: MyCollection myCollection = (MyCollection)SampleServices.GenerateCollection(200);

    9:  

   10: System.Diagnostics.Trace.WriteLine("3. CUSTOM COLLECTION CREATED");

   11:  

   12: DataTable datatable = SampleServices.ConvertCollectionTableIntoDataTalbe(myCollection);

   13:  

   14: System.Diagnostics.Trace.WriteLine("4. CUSTOM COLLECTION CONVERTED INTO DATATABLE");

   15:  

   16: datagrid.DataSource = datatable;

   17: datagrid.DataBind();

   18:  

   19: System.Diagnostics.Trace.WriteLine("5. DONE");

Note, that UseCustomCollection.aspx.cs misses step “4. CUSTOM COLLECTION CONVERTED INTO DATATABLE”.

Collecting Execution Times

We used DebugView to collect reported execution times.

Analysis

Applying simple mathematics we can see that converting Collection to Datatable takes 0.00081015 seconds.  This is the gain we get when skipping this step in UseCustomCollection.aspx.cs.

Now lets examine DataBind() in both cases:

• UseCustomCollection.aspx.cs 0.00268023 seconds
• UseDataTable.aspx.cs 0.00215912 seconds

I know it is not a huge improvement for binding datatable vs. collection, but the tests we conducted always showed this gap. That is why eliminating the type transformation from collection to datatable that included enumeration and looping did not really help and we ended up with similar results of ~65% CPU utilization:

UseDataTable.aspx	UseCustomCollection.aspx

Conclusion

Binding custom collection is expensive performance wise since internally it uses reflection and reflection is expensive thing to do. Looping is expensive performance wise too but it is cheaper than reflection.

Related Materials

• Use FREE Tools From IIS Resource Kit To Warm Up Your ASP.NET 1.1 Application By Batch Compilation
• ASP.NET Performance Engineering - Stress Test Your Architecture, Design, And Code
• Performance Sin - Chatty Database Access And Loops (Plus Another Free Performance Tool)
• Stress Test ASP.NET Web Application With Free WCAT Tool
• Performance Code Review Tool – Practices Checker

Comments

• Anonymous
  August 01, 2008
  The comment has been removed

• Anonymous
  August 01, 2008
  Something is wrong on your own numbers:the 1st one (customecollection) shows 0.0043the 2nd one (datatable) shows 0.0047 So the 2nd one is slower.

• Anonymous
  August 01, 2008
  Hi, Israel!Interesting remark.Look at what PAG says about that:http://msdn.microsoft.com/en-us/library/ms998549.aspxlook at "Minimize Calls to DataBinder.Eval" in itI guess I need to do more testing - thansk for calling this out!

• Anonymous
  August 01, 2008
  The comment has been removed