ajax or not to ajax.

Heres a strange one for you. I have a textbox, a button and a gridview on a page. I enter some search text which returns 500 odd records in under a second. When i wrap the gridview in an updatepanel, set its update mode to "conditional" and the trigger to the button the page can take 2-4 seconds to render.

I think the problem is down to page redering some how as my progress indicator stops at around the same time as the normal postback would appear.

0
Lee
8/10/2007 1:48:55 PM
πŸ“ asp.net.ajax-ui
πŸ“ƒ 9760 articles.
⭐ 0 followers.

πŸ’¬ 7 Replies
πŸ‘οΈβ€πŸ—¨οΈ 3371 Views

I have also noticed this very behaviour and have come to the conclusion that in cases like this it is better to hand code a XMLHttp call to a webservice. The updatepanel and gridview combination is not very efficient if you have a large number of records.


Regards,
Prashant


Dont forget to click "Mark as Answer" on the post that helped you.
0
Prashant
8/10/2007 2:23:04 PM

Tables aren't known for their lightning fast rendering speeds, in general.  It likely takes just as long to render in a full postback, but you wouldn't notice as much due to the full page refresh.

The UpdatePanel mechanism itself isn't going to affect the speed of that.  All it does is retrieve newly rendered HTML and replace the UpdatePanel's div's content with that.  There is no actual post-response rendering overhead caused by an UpdatePanel. 


Encosia - ASP.NET, AJAX, and more.

Latest article: Using complex types to make calling services less… complex
0
gt1329a
8/10/2007 5:19:54 PM

Hi, and thanks for the replys. I agree with what your saying but there really is quite a performance impact and in fact so much that i have gone back to using postbacks rather than an update panel. The lag seems to be with rendering to the fresh content.

0
Lee
8/13/2007 7:25:04 AM
The problem is that browsers render large tables slowly, regardless of the UpdatePanel.  If you dynamically generated a large table using JavaScript on the client side, with no AJAX, and added that to the DOM, you would see the same slow rendering.

Encosia - ASP.NET, AJAX, and more.

Latest article: Using complex types to make calling services less… complex
0
gt1329a
8/13/2007 2:02:25 PM

ok, thats crystal clear now thanks. So in essence this is a big problem if your using a gridview. Would customising the output from tables to divs improve the situation.

0
Lee
8/13/2007 3:27:02 PM

Divs usually render faster, yes.


Encosia - ASP.NET, AJAX, and more.

Latest article: Using complex types to make calling services less… complex
0
gt1329a
8/13/2007 4:00:54 PM

The original posted problem is an interesting one.  The issue at hand is not really slow rending of the table.

 Example:

1. Create 2 tables on a page.  On page load, put a table with 5000 rows in the first table.  Create a button that will trigger a postback.  In the event, clear out the original table and add the same data into the second table.  The action here is to move data from one table to the other.  Now run the page.  You will notice that there is a slight load time for the table, but it is less than a second.  The tables render very quickly.

2. Now, add update panels around both tables.  Have the button trigger a partial page load that will move the data from the first table to the second table.  Include an update progress bar with an animated gif in it.  Now click the button to do the transfer and you will see the update gif go for about a second then stop.  This signifies that the server code is done running and now the client side code is doing rendering (or something, I have no idea).  Everything in the page will seem to freeze for a long time, at least 10 seconds.  This is unreasonable.

3. There is a work around for this.  When you click the button, you will want to run some javascript before the async postback.  This javascript should clear out the contents of the first table.  Now deleting rows in a table that big is not quick, so the best solution is to put a div around the table and set the innerHTML of the div to "".  This clears out the html of the large table and somehow makes the partial postback happen as quickly as a regular postback with no delays.

This is very odd behavior and I believe it is an issue with internet explorer rendering code.  I tried the above example in step 2 with firefox.  I experienced no delays.  As for IE, the workaround in step 3 works, but I don't know why.  If anyone has any extra light to shed on this subject, I would love to know.

0
bunkscene
11/8/2007 2:44:20 PM
Reply: