Nowadays, component vendors tried to come up with amusing marketing campaigns, and some of them claimed that their ASP.NET Grid is the fastest and they even show a comparison to two industry’s leading Grid product in their live demo, although they didn’t mention the names. Due to the privacy and sensitive nature of this post, I won’t mention that vendor’s name here and I will use an initial “XGrid” to refer their Grid in this post.
At first, we don’t bother to check the accuracy of their claim as it has nothing to do with our products. However, recently, I’ve become aware of several customers who demanded to know the performance comparison between “XGrid” and our WebGrid. In this post, I’m going to share my experience with the performance testing, and learn how we addressed such scenarios for large enterprise-ready usage.
Toward that curiousity, I’m conducting a performance testing, both are using live deployed samples. Here are the results:
“XGrid”, claimed to be the fastest Grid and claimed to load 300k data < 2 seconds. The fact is it loads averagely in 6 seconds. See following screenshot.
WebGrid.NET Enterprise 6.0 (coupled with flagship ISDataSource for advanced load-on-demand feature), tested to load 350k data < 2 seconds. See following.
Now that you’ve seen the runtime performance comparison, how about the memory consumption? “XGrid” claimed that it took less than 10MB in memory consumption, that’s good enough while other products may take at least 500mb in this kind of operation. The 500mb memory consumption is unavoidable since most Grid products depend on .NET’s DataSet which took around 400MB in a simple “adapter.Fill(dataSet)” syntax.
WebGrid.NET Enterprise 6.0, coupled with ISDataSource 1.0 in the 2008 release significantly reduces memory consumption when loading from such large table. ISDataSource incorporates an advanced load-on-demand technology, which seamlessly connected to WebGrid in order to provide high-performance results.
Surprisingly, our WebGrid took only < 5MB memory consumption for databound operation. The following arethe memory snapshots of the w3wp process after performing 2 times paging, and sorting, respectively.
ISDataSource features unique capabilities and bare-metal architecture which offers greater flexibility and customizability. When used in WebGrid, it extends several advanced functionalities such as ability to perform custom filtering and sorting, custom data aggregation, and so on.
In this sample, sorting, paging, filtering and data aggregation are applied on global data, instead of the paged data. It is made possible with ISDataSource’s flexible architecture and event handling so that extra scenarios can be handled in the provided events.
Our sample is using our unique ClassicPaging feature, combined with Custom Load-on-Demand setting, and Custom Aggregate-Retrieval for ColumnFooter setting. Note that you need the latest WebGrid 6.0 and ISDataSource (2008 R1+) to simulate this test. The comparison is an “apple to apple” measurement and it’s loaded on a table with over 350.000 rows, note that aggregate functions on the column footer are returning all data rows (and not the paged data). And still, our performance is far more faster than “XGrid”, and our memory usage is less than 5 MB (while they took < 10MB). To experience it yourself, point your browser to this sample. Seeing is believing 🙂
Needless to say. It is well proven that our flagship WebGrid.NET Enterprise 6.0 is still the most advanced and innovative ASP.NET Grid, with unmatchable performance and unique capabilities to address enterprise-level data scenarios.
If you’re interested further in learning about performance topic, please write your comments and questions in this post. Hopefully you find this post useful in your evaluation on performance and related topics.