How much difference will there be if I bind data to a gridview in comparison to a loop through the data and build out the Html?
I am currently using an html table in the ItemTemplate of a gridview and have <%#Eval("ID")%> in that table to bind the data from iQueryable
What if i loop through the IQueryable and build out html from the code behind instead. How much is the performance difference if someone has done that comparison or has good knowledge of which should be the way to go ?
Thanks.
I am using Asp.net /C#
Generally speaking the performance benefit of avoiding complex controls and binding is not measurable on an individual page level, and thus inconsequential. The developer time saved in using existing controls and simpler api's, like data binding, greatly outweigh the small performance hit.
In our main application, we use complex controls and data binding throughout the ASP.NET page. The data binding portion of the full page life cycle is under 2% of the time to process the whole page. It's much less than the I/O for the page and particularly the DB calls.
One exception is in reports. The reporting engine we use supports directly setting data in a loop or using data binding. Data binding is much easier. However, with some reports hitting 200+ pages with over 300,000 bound data items, the performance hit of data binding was noticeable in this case. In our reports, we don't use data binding.
Related
whats are methods to keeping datasource for a gridview.
situation :
I have a query which can take 5 to 10 seconds (a lot of link on a lot of data).
The result is too big for a page so I have a paging on my grid.
But, every time I use the pageIndexChanged, I need to get the datasource again.
So I want to know how I can keep my datasource.
Is it possible? NOT by session.
It is possible, I have used a custom (server-side) viewstate provider to cache your datasource.
*Updated: There is a pretty good article on custom viewstate providers (with sample code) here: http://www.codeproject.com/Articles/8001/ViewState-Provider-an-implementation-using-Provide
However, I would strongly recommend improving your query to limit the data to that which the user really wants to see. Large grids that have many more rows than the user is truly interested in are unwieldy from memory, processor, bandwidth, and user-experience perspectives. Try to find a better way.
I have a gridview with about 300-400 rows that I use for reporting; it needs paging and requires sorting. My choice is between these two options: a) load the 300-400 in one query and let the gridview do the paging and sorting; b) handle the paging/sorting at the data source level. I know that b) is going to be better/faster/more efficient... In my context, I'm looking to get something done relatively fast; if I choose a), will the page seem incredibly/painfully slow?
Thanks.
Use the builtin functions of the GridView and load the whole data at one go. It wouldn't be worth the effort to implement paging in database(f.e. with RowNumber) when your number of records is such small, especially because you mentioned that you are looking for a fast solution. When you enable paging in GridView the performance will suffice.
read Scott Guthrie's excellent article about paging.
How to implement a data-result search page built with ASP.NET 2.0 and Atlas that can present hundreds of thousands of row results using the ASP.NET 2.0 GridView control. The results are formatted using a “paging” based UI model – where 15 results per page are displayed, and the user can skip from page to page to see their data. For kicks I also added support for editing and deleting each individual row.
Although 300-400 rows isn't a particularly large set of data, I would certainly vote for option B since it will definitely be more scalable. Once you start getting massive sets of data, loading all of it with one query and having the GridView handle the paging will end up being incredibly slow. The better option is to, like you said, only query the data you need for each page.
However, if you aren't going to have data sets larger than 300-400 records, you probably don't need to be too concerned about load times, but again, the key is in scalability.
I'm building a asp.net web application with lots and lots of controls and huge volumes of data. My application is very slow and it is taking a large amount of time to load the data into the .net controls like grid, tree view etc. I also have some ajaxified pages and controls in my application. I want to reduce the page load time in each postbacks.
What are the standards/best practices to be followed while developing large asp.net applications?
Thank you.
NLV
Cache certain data, either in the application or in the database (thus breaking normalization but it's okay)
Retrieve the minimum subset of data you really need. Don't pull 10000 records from the database into a grid to only display 50. Query for exactly 50.
Mimimize the amount of server controls and dynamic markup creation. Replace what you can with passive HTML elements.
Switch off the view state, which can potentially expand pages to many megabytes in size. Pull the data from the database on each request (in combination with caching strategies).
You Can use JQuery to retreive the data from database which is much better than using ajax. Check this http://www.codeproject.com/KB/webservices/JsonWebServiceJQuery.aspx
Say I have 2 tables in a database, each with 100,000's of rows in detail and 10,000's of rows in the master 5 columns each, properly indexed and related. I want to have master/detail nested gridviews. What's the fastest architecture I could design in .net to do this? The largest result set on the master could be in the thousands (usually in the tens though) and the detail per records could be in the hundreds (usually in the single digits though). I'd like to be able to do a display all masters if possible.
The bottom line: bind to DataReaders, use Repeaters instead of GridViews, and turn off ViewState.
The design you're proposing is going to be pretty hard on your users (thousands of records, yikes), but you probably already know that.
If this is just for display and you want the absolute fastest architecture for Asp.Net, you should obtain an IDataReader for each data segment (master and child), sorted such that you can manually match child records while reading both resultsets in a forward-only fashion. (See Scott Mitchell's Why I don't Use DataSets in my ASP.NET Applications for some details about DataReader performance - as long as you aren't optimizing prematurely, it's quite good advice.)
Instead of using a GridView, I'd use a Repeater which has less overhead and lets you write more compact HTML (for a smaller payload to the client): bind the master IDataReader to that repeater. (I'm not sure whether you meant the GridView control, or just a conceptual grid - the basic architecture would be the same for a GridView)
Then add a handler to the Repeater.ItemDataBound that checks if the child data reader's current record matches. If it does, manually render your detail data for that master record.
Finally, you should also turn ViewState off, at least for the Repeater (preferably for as much of the page as possible), again so that the HTML payload is smaller.
If you're totally committed to nested GridViews, particularly to using a GridView to render the detail data, it's going to hurt the performance one way or another, because you'll have to either make many more database calls (to obtain discrete resultsets you can bind to) or you'll have to massage the detail data into an intermediary container.
My DAL is created using Linq and all is fine. However, on one page, I'm to display a table (gridview) which pulls data from a SQL Server database table. However, I've heard many warnings about staying away from using any of the built in controls (ObjectDataSource and SQLDataSource). Is there any truth in this, regarding scalability/efficiency? I posted a similar problem before but, in this case, I have direct access to the server. What would be the best way to bind the data to gridview? I can't cache the data as is it tailored to individuals and I'd rather not store them in sessions as there could be between 100-200 custom objects being called. I haven't really dabbled in SQL, but with a bit of reading, I'm sure I could create my own custom server side paging/filtering/sorting. Would it be efficient if I created a stored procedure for each of these functions and called them from an objectdatasource, or should I call the SP using Linq to SQL (in my DAL) and then display that information directly to the gridview?
Thanks for any advice
There is nothing wrong in using a grid view, or custom object data source, if it is only for some hundreds of records. Scalability is an issue for thousands of records. Fastest Access possible would be via a DataReader filling a Datatable. Binding gridviews to a Datatable is always a good idea for a large number of records, as binding is fast and sorting also.
I have therefore written a library called modelshredder that can translate any IEnumerable collection of objects into a DataTable. It uses dynamically emitted code to do its Job, that's why it's fast enough for thousands of records. You can use plain linq-to-sql to write and execute your query, prefetably project into an annonymous type and call .ToDataTable() on the result.