c# data matrix render PAGE OBJECT INTERNALS in Visual C#.NET

Encoder DataMatrix in Visual C#.NET PAGE OBJECT INTERNALS

We ve examined how all of the work you do while an ASP .NET page is processing is stored as state of control objects in the control tree. We ve also examined how no markup is committed to the output stream until after all of your code has executed, most specifically, after the PreRenderComplete event fires. But what about data binding Surely when the DataBind method is called, the bound control generates HTML that s committed to the output stream right away, doesn t it The answer is most definitely no. Data binding is no exception to the rule. When DataBind is called, the control doing the binding generates any number of instances of objects that it stores in its own collection. List controls generate ListItem objects. The DataGrid generates DataGridItem objects. Each data bound control has its own type that it uses to represent an individual row in what eventually will become the HTML output stream. Because these collections of items are a contained collection of the bound control, the binding operation is really state information stored in the control tree. When Render is called on the bound control, the control iterates over the objects in its particular item collection, transforming each into HTML. The DropDownList generates option tags. The DataGrid generates table rows, and so on.

If this comes as a surprise to you, it s going to come as an absolute shock what happens with memory consumption during this process (see Figure 3-19). Carefully consider the resources you re consuming when you re binding a DataGrid to a DataSet with the following code: private void Page_Load (object sender, System.EventArgs e) { SqlConnection cn = new SqlConnection("server=.;database=pubs;uid=sa;pwd="); SqlCommand cm = new SqlCommand("select * from authors", cn); SqlDataAdapter da = new SqlDataAdapter(cm); DataSet ds = new DataSet(); da.Fill(ds); DataGrid1.DataSource = ds.Tables[0]; DataGrid1.DataBind(); } //Page Rendering

Figure 3-19. Consumption of resources while data binding The first hit you take on the web server s memory is when you call Fill on the DataAdpater. This marshals your entire result set from the database into the process space of the web server. The DataSet carries not only the current values as read from the database, but also the original values as the data was read out of the database, as well as metadata about the structure of the DataTable objects contained in its TablesCollection. The DataSet is a very powerful object, but it s also a very fat object. You take a hit whenever you load one into memory. If you re doing this on your home page, you re taking this hit not once, but once for each user that comes to your site. But wait, it gets worse. The next thing you do is set the DataSource of the DataGrid and call DataBind. As we just went over, this creates an in-memory collection of DataGridItems. This collection is probably just as large as your DataSet. If you re only outputting a couple of columns, maybe it won t be as large. If you re using a complex column template with a lot of markup, the size of this

collection could exceed the size of the DataSet. So at this point you ve got about a 2X hit on the web server memory (X being the size of your result set). After that, your code is done executing. Your DataSet goes out of scope, but the DataGrid won t go out of scope until you re done rendering. Furthermore, the DataSet hangs around on the managed heap until the garbage collector does a couple of sweeps, which probably won t happen until after your rendering is complete. So as you enter the rendering stage of your Page object, we re still holding onto memory resources of the web server equal to approximately twice the size of the result set. When the DataGrid renders, it does a couple of things. First, it transforms its DataGridItem collection into HTML. This is, again, probably as big as your initial result set, so you re at 3X memory consumption. Then the grid squirrels away all of the DataGridItems into the ViewState of the page. After all, it will need these to restore its state when a postback occurs. If it didn t hold onto these, the grid would need to be rebound on every postback. 4X the size of your result set in web server memory resources is consumed. Swap out X for a 250K result set and multiply that by your number of concurrent users. You can see this rather innocuous operation gets very expensive very quickly. So what do you do You have a number of options. Which one you employ depends upon your requirements. The first option is to use a DataReader instead of a DataSet. A DataSet is an in-memory representation of your result set. Having this in memory is very nice for a number of things, such as sorting, filtering, caching, modifying, and marshaling. However, in this case, you re doing none of those things. In fact, a DataReader is ideal for binding operations when you re generating markup. You don t need all that data in memory at once! A DataReader reads a row at a time from the database, and then discards it. So as you move through the result set, you maintain a nice low memory footprint, equal to the size of one row of your result set. The DataReader is not suited for all purposes. You can only read forward through the DataReader once. You cannot modify data. You cannot cache a pointer to the DataReader or marshal it across processes. When you have the need to do these things, by all means use a DataSet. Just don t go to the DataSet unless you have a specific requirement that drives you there. The next thing you can do is disable the ViewState on the DataGrid. ViewState is nice, but for a DataGrid it s generally too expensive, especially if you have dial-up users. Not only does it bloat the size of the response stream, but also the whole thing gets sent back to the server when a postback occurs, so it bloats the size of any subsequent HTTP request on a postback as well. Your page is generally going to get better performance by rebinding the grid when the page posts back. This won t work for editable grids, but for most of the rest of the functionality, this pattern should serve you fine. Of course, if you re writing an Intranet application and it s only ever going to run on a 100-mbps connection, ViewState bloat might not be a big deal, and you may get better performance using it than re-binding on every postback. These options should be put under a load that approximates the conditions in your production environment as closely as possible, and then you can see which one is faster. (See 4 for further discussion of ViewState, and the new 2.0 feature, ControlState, which helps to manage this problem in many circumstances.) You can also mitigate the impact of both the DataSet size and the resources the DataGrid consumes by binding to smaller result sets. If this isn t an option because you have large result sets, then use the custom paging feature of the DataGrid, and implement paging at the database level. The automatic paging feature of the DataGrid is not a good solution to the problems