Alik Levin's

Clarity, Technology, and Solving Problems | PracticeThis.com

Best ASP.NET Performance Winner For Data Binding - Hands Up To Response.Write()

Best ASP.NET Performance Winner For Data Binding - Hands Up To Response.Write()

  • Comments 21

Alik Levin     To achieve best performance you need to make decisions based on trade-off between coolness, coding productivity, and personal engineering values. I never thought I would be recommending my customer considering using old fashion Response.Write() in his Internet facing ASP.NET web application in order to significantly improve the application’s performance.

Customer Case Study

During load/stress testing customer’s ASP.NET web application we identified high CPU utilization (up to 90%). After quick investigation we noticed that %Time in GC performance counter is less than optimal. Our assumption was that the application uses memory allocation techniques that are less than optimal. From GC Performance Counters:

"First thing you may want to look at is “% Time in GC”... What is a health value for this counter? It’s hard to say. It depends on what your app does. But if you are seeing a really high value (like 50% or more) then it’s a reasonable time to look at what’s going on inside of the managed heap."

Another resource we used is timeless patterns & practices’ Chapter 15 — Measuring .NET Application Performance:

.NET CLR Memory\% Time in GC

"…The most common cause of a high value is making too many allocations, which may be the case if you are allocating on a per-request basis for ASP.NET applications. You need to study the allocation profile for your application if this counter shows a higher value."

So we headed to looking into the code and this is what we found out.

Analysis

During performance code inspection we identified massive usage of collections. The collections were used to transfer the data between the logical layers and then the collections were transferred into datatables to be bindable for DataGrid (yes, it is .Net 1.1 app).

Eureka! We just spotted 3 performance anti-patterns. Massive memory allocation, massive loops, massive type conversions. I’ve shown it to 4 very respected professionals and everyone was saying the same – current situation is pure performance anti-pattern. Here are few suggestions that came up:

  • Bind collections directly to DataGrid eliminating additional memory allocations and loops.
  • Create Datatable directly from XML skipping collection creation step eliminating additional memory allocations and loops.
  • Use Xslt transformation transforming original Xml into Html table using Xslt elminating memory allocations and loops for both collections and datatables.
  • Use Response.Write() as it’s suggested by patterns & practices:

"Use the Response.Write method. It is one of the fastest ways to return output back to the browser."

Case close? Not really...

Secretly I’ve built Visual Studio 2003 project with these implementations and ran simple stress test using TinyGet utility. The results left us all a bit surprised.

Converting Collection To Datatable (Current Situation)

The code:

   1: //create custom collection
   2: MyCollection myCollection = (MyCollection)SampleServices.GenerateCollection(200);
   3:  
   4: //convert collection to datatable
   5: DataTable datatable = SampleServices.ConvertCollectionTableIntoDataTalbe(myCollection);
   6:  
   7: //bind datatalbe to dynamically created datagrid
   8: datagrid.DataSource = datatable;
   9: datagrid.DataBind();
 
The stress test:
 
tinyget.exe  -srv:192.168.50.68 -uri:/dynamiccontrolsloadingrelease/UseDataTable.aspx -loop:100 -threads:15
 
The result:
 
image

Bind Collection Directly To Grid

The code:

   1: MyCollection myCollection = (MyCollection)SampleServices.GenerateCollection(200);
   2:  
   3: //bind datatalbe to dynamically created datagrid
   4: datagrid.DataSource = myCollection;
   5: datagrid.DataBind();

The stress test:

tinyget.exe  -srv:192.168.50.68 -uri:/dynamiccontrolsloadingrelease/UseCustomCollection.aspx -loop:100 -threads:15

The result:

image

 

Create Datatable From Xml

The code:

   1: string xml = SampleServices.GenerateXml(200);
   2:  
   3: StringReader theReader = new StringReader(xml);
   4: DataSet theDataSet = new DataSet();
   5: theDataSet.ReadXml(theReader);
   6:  
   7: datagrid.DataSource = theDataSet.Tables[0].DefaultView;;
   8: datagrid.DataBind();

The stress test:

tinyget.exe  -srv:192.168.50.68 -uri:/dynamiccontrolsloadingrelease/LoadXmlIntoDataTable.aspx -loop:100 -threads:15

The result:

image 

Use Xslt Transformation To Create Html Table

The code:

   1: Xml1.DocumentContent = SampleServices.GenerateXml(200);
   2: Xml1.TransformSource=@"xsl.xml";

The stress test:

tinyget.exe  -srv:192.168.50.68 -uri:/dynamiccontrolsloadingrelease/XmlXslTransformation.aspx -loop:100 -threads:15

The result:

 image

Use Response.Write()

The code:

   1: MyCollection myCollection = (MyCollection)SampleServices.GenerateCollection(200);
   2:  
   3: // Put user code to initialize the page here
   4: Response.Write("<table>");
   5:  
   6: foreach(MyModelItem item in  myCollection)
   7: {
   8:  
   9:     Response.Write("<tr>");
  10:     Response.Write("<td>" +  item.Address  + "<td>");
  11:     Response.Write("<td>" +  item.City  + "<td>");
  12:     Response.Write("<td>" +  item.Education+ "<td>");
  13:     Response.Write("<td>" +  item.Family  + "<td>");
  14:     Response.Write("<td>" +  item.Name  + "<td>");
  15:     Response.Write("</tr>");
  16: }
  17: Response.Write("</table>");

The stress test:

tinyget.exe  -srv:192.168.50.68 -uri:/dynamiccontrolsloadingrelease/ResponseWrite.aspx -loop:100 -threads:15

The result:

image 

Sample Visual Studio 2003 Project

Interested in testing it yourself? Grab the source code from my SkyDrive here:

Conclusion

After conducting this simple test these are the conclusions I’ve made:

  • “Don't be afraid to challenge the pros, even in their own backyard." - How to Get Things Done - Colin Powell Version
  • Testing IS DA thing. Assumptions are good but nothing speaks louder than facts.
  • Test early - avoid massive rework afterwards. Create POC's (Proof of concept) early in architecture/design stages.
  • Best performance comes on expense of productivity and coolness.

Related Materials

  • You've been kicked (a good thing) - Trackback from DotNetKicks.com

  • Really nice.  I love how thorough you were in the investigation and in reporting the results.

    Thanks for taking the time to put this together.

  • James, great to hear you found this useful

  • &#160;&#160;&#160; In my previous post -&#160; Best ASP.NET Performance Winner For Data Binding - Hands

  • Well, I see a major flaw in this test since datagrid is not rendered into the pure html table actually.

    You'd better test this vs. repeater and even repeater supports a bunch of events like itemdatabound and itemcreated.

  • Another week of great resources for the .NET developer to take in. Amazing how many are out there. I

  • Anatoly,

    Thanks for the resourceful remark!

    My intention was to take customer's code and test it as is. There is simple meta pattern - developers code, end users use, IT guys support. All iwanted is to model what would it feel like for end users and IT guys when developers code the way they code (and as I just witnessed it)

    Repeater is another test I should have consider though - thanks for calling it out!

  • Thanks for an interesting post!

    One question; did you exclude using StringBuilder on purpose?

    If not, it may be worth testing the "Response.Write" against using a StringBuffer to see how tha compares...

    Cheers,

    Joakim

  • Joakim,

    Thanks for the insight!

    Few folks called this out too. I did not use StringBuilder originally as I was lazy to do so. In any way it would only improve it, right. But then I've built the demo that uses StringBuidler and there were no significant improvements.

    Next post is about using Repeater and ItemDataBoubd event as another reader called out Nice results BTW :)

    thanks for checking in.

  • Hi, I think you could make the Response.Write even faster if you avoided the string concat inside of them.

    Response.Write("<td>" +  item.Address  + "<td>");

    might be better written as

    Response.Write("<td>");

    Response.Write(item.Address);

    Response.Write("</td>");

    I think that might reduce string concat.

  • Also I think Response.Write just uses a stream which will perform as well or better than StringBuilder. Or at least it should :)

  • Sam,

    Thanks for the insight

    few pointed this one out too, see my prev response[.Write ] :)

    Just looked at your web site - oh, lala! Bookmarked

  • Note that Databinding is doing some additional stuff like cross-site-scripting checks, etc. that ideally you'll need to do if you use this method.

  • Daniel!!

    That is perfect remark. Not perf wise but security wise.

    Brilliant!

    I do not think that applying htmlencoding will add to much burden vs reflection Databinding does, but i must appreciate your comment.

    See, security and perf, has never been good friends

    Very good catch!

  • This is not a comparison between datagrid with reponse.write.

    Have you profiled it to find out what the real performance bottle neck is? Did you try it with serveral different datatypes?

    What is the influence of looping through the datagrid and then casting to myCollection?

    You can make a better benchmark to isolate the code before the databind() call and before the foreach loop in the other version.

    I have tried this before and I'm sure you will get totally different results!

Page 1 of 2 (21 items) 12