Hello all,

Can anyone enligthen me as to why this behaviour happens?

Ok, I have been working on this asp.net site which is due to release in early january. The portion i am working on right now is performance.

My first question is :

During general browsing between sites, i get this blank white screen while the current page does it's databinding and thinking and what not and also it waits for a majority of the Jpeg's to download as well and displays it all at one time. FYI this page is a gallery view of a set of pictures, each thumbnail is 6k, and there are 30 on one page.

Is there any way to have the asp.net page display the html right away and have the images load in a timely fashion? because for general user experience purposes, it sucks to stare at a blank screen for 2 or 3 seconds while all images are being downloaded!

Second question:

I want to know straight up that is databinding the fastest solution to displaying a list of items? Do you gain better performance in doing spagetti code and simply looping within the html page instead of databinding in the codebehind file? I mean that is one of my current issues with performance. Databinding just doesn't seem to go as fast as i would like it to. It also seems like it is holding the page and giving the blank screen while it builds all html then proceeds to serve it out to the client at one time.

I want the html to be outputted as it comes in a timely fashion, not is one huge glob!

Any suggestions?

thanks all!

Flyin

I doubt you'll (no you personally) be able to write a speghetti loop that is better than databinding. Your time would be better well spent optimizing the data behind the binding.

One thing that could be affecting the image problem could be lack of explicit size attributes. If you set specific sizes for the images than the browser will display the HTML before it needs the images because then the browser doesn't have to get image information so it knows how to display the image. Of course, newer browser i.e. (not sure how far back) and others paint the page a bit more dynamically so they usually don't have a problem with the lack of size attributes.

Another thing you might look at it is the page trace information. Turn on tracing and see how long the various function calls take. You might be surprised that the page generates pretty fast but takes a while to load due to HTML weight or other bandwidth specific issues.

You could also turn on smart navigation which performs a kind of "background load" of the page when you post back. This probably won't help href links to pages, but it's worth looking into if you post back a lot.

In the ASP days, I used to sometimes employ the use of Response.Flush which forces the stored up HTML to be released to the browser. However, this actually caused the page to perform worse in some cases. It was better to buffer the HTML and then flush at the very end. With .NET this concept is more or less moot. When you do stuff in the page execution, no HTML is generated until the render event of the page. So I don't think you can't tell it to push HTML out to the browser. Even if you could, I'd recommend against it.

Like I mentioned before, look into the code that's already there. See how your DB calls perform. Use tracing to track the time of DB calls. Perhaps caching of datasets would help if it's possible.

thank you very much for the thorough response.

Yes i've done the debug tracing and that was what prompted me to post my question.

Through the trace, i was seeing that once the data was cached, it took 0 time to retrieve, but about 3-4 seconds to databind the data. The Flush at the end was not too bad though.

Are there databinding techniques out there that i should be aware of?

Do you override the databinding class and make your own tweaks to it?

My Item templates are pretty heafty which is probably the bulk of the slowness, but unfortunately the html cannot be shrunk at all so thats why i need to know if there are certain tweaks i can do to the databinding that would bind data faster or what not.

Thanks again for the input.