To Response.Write or Not to Response.Write

**Al Smith** · Dec 21st, 2001, 03:24 PM

Hi,
Are there pro's or con's to either of the below?
One breaks out of asp to do the HTML the other Response.Writes the HTML.

Thanks,
Al.

Code:

<TD colspan="4" align="center">
<%If CallWork="Completed" then%>
      <Input type=submit name="btn" value="Report Parts Used">&nbsp;
      <Input type=submit name="btn" value="No Parts Used">&nbsp;
<%Else%>
      <Input type=submit name="btn" value="Enter Repair Text">&nbsp;
<%End If%>
      <button type="reset">Clear Form</button>&nbsp;
      <button onclick="history.go(-1)"><font color="blue"><b>Back</b></font>

</TD>

Code:

<%
With Response
      .Write "<TD colspan='4' align='center'>"
If CallWork="Completed" then
      .Write "<Input type=submit name='btn' value='Report Parts Used'>&nbsp;"
      .Write "<Input type=submit name='btn' value='No Parts Used'>&nbsp;"
Else
      .Write "<Input type=submit name='btn' value='Enter Repair Text'>&nbsp;"
End If
      .Write "<button type='reset'>Clear Form</button>&nbsp;"
      .Write "<button onclick='history.go(-1)'><font color='blue'><b>Back</b></font>"
      .Write "</TD>"
End With
%>

**Serge** · Dec 21st, 2001, 03:33 PM

It is better to use Response.Write instead of mixing HTML with ASP script. with Response.Write you write to the page once where with mixed state you're going back and forth from the server to the client.

**Al Smith** · Dec 21st, 2001, 06:29 PM

Thanks for the reply.

What does that affect? e.g. Response time?, Server Resources, ???

Al.

pvb · Dec 21st, 2001, 09:52 PM

While it's correct to say that using Response.Write is better the reason is incorrect. When you use inline asp tags, the hang up is not going back and forth from server to client, the issue is known as Context Switching; that is, IIS has to keep switching from pumpin out pure html to processing script and vice versa.

Using repeated Response.Write statements for every line of asp is not much better either, the bottleneck then becomes all the function calls to Response.Write.

Wayne Plourde wrote a couple of great performance comparison articles for asptoday.com showing benchmark results of various techniques of asp processing. One of the best results was when Enable Buffering was enabled on the server(this is the default for IIS 5.0) and concatenating consecutive Response.Write calls into one statement.

Code:

Response.Write ("<html><body>" & _
  "<table>" & _
  "<tr><td>First Name:</td><td>" & sFirstName & "</td></tr>" & _
  "<tr><td>Last Name:</td><td>" & sLastName & "</td></tr>" & _
  "</table>" & _
  "</body></html>")

With respect to going back and forth from server to client, it really doesn't go back and forth at all. The two basic options you as the developer have are 1)process the entire asp page first, and once the whole page is completely ready, write the results to the client or 2)write the results to the client as the page is processing. You've probably seen each of these two scenarios somewhere on the web before. The page you surf to that is blank, blank, blank and then boom, the whole page is visible in the blink of an eye. That was probably scenario 1, waiting for the entire page to load/process before showing the client(browser) anything. Then there's the page you go to, and even though you see some content, the browser looks like it's still working; that's probably because it's the second scenario, showing the page as soon as the data becomes available, rather than waiting for the whole page to finish. Benefit of the first scenario can be speed and less network traffic(less net traffic because you're not constantly writing a stream to the client). The setback is server resources, all those pages that are waiting until they are completely ready to deliver have to go somewhere in the meantime, and that means RAM. Not a big deal if you only get 10 hits on a page per day, but it starts to really add up the more requests per page you get. Benefit of the second scenario is that you conserve more server resources(you're delivering the content as soon as you can and thus freeing up server resources for more pages) and makin the user probably a little happier as they get to see something right away instead of having to wait a couple of seconds for the whole page to deliver.

Another technique is xml/xsl transformations if the situation calls for it. This consists of loading up your xml data and slapping an xsl stylesheet against and doing a single Response.Write(writing the result of the xml/xsl transformation).

Best way of deciding which technique to use is to test out your pages using different techniques and see which one works best for your situation.

**Al Smith** · Dec 21st, 2001, 10:16 PM

Thanks for the very informative reply. That explains the scripts I've seen where the HTML code is built into a string throughout the asp process then one Response.Write sends the whole thing.

Would you happen to have a link to Wayne Plourde's articles?

Thanks again,
Al.

**JoshT** · Dec 26th, 2001, 07:59 AM

And if you switch from VBScript to PerlScript for your ASP coding, in my experience PerlScript's string concatenation is significantly faster (like 400% or so).

**CiberTHuG** · Dec 27th, 2001, 11:02 AM

Wow... ignorance runs rampant.

First, this has nothing to do with going back and forth between the client and server. It isn't until the entire page is written does any of it go to the client.

Secondly, using string concatenation is an entirely different beast than using the Response object's Write method. VB/VBScript's string concatenation is miserably slow. As Josh pointed out, Perl/PerlScript has worked to improve string performance. Context switching is handled by the server however, and not the language you use.

Thirdly, yes, context switching and excessive calls to a single object have their drawbacks, as some one pointed out. But you have to weigh: how large is your page? how powerful is your server? how easy is the resulting code to maintain?

If you need to, just run some benchmark tests with your page both ways. I don't shy away from context switching since it isn't horribly slow and is terribly easy to read. But that is just me.

Aside from all of that, I would honestly imagine that if the server were worth its code in gold, context switching would me notably faster than anything else. Especially since I'm under the impression the ASP pages are cached by the server the first time they are assembled. If you find context switching to be slow (which you probably will) then I blame whoever wrote ASP for doing such a poor job.

pvb · Dec 27th, 2001, 04:02 PM

Wow... ignorance runs rampant

Since everything i mentioned is indisputably correct and/or based on actual performance tests rather than "expert opinion" I'll assume i was not the target of that comment. But speaking of ignorance,

It isn't until the entire page is written does any of it go to the client.

Uh, check your documentation. That's only true if Buffering is enabled(as i explained). Read up on Response.Buffer and Response.Flush.

If you find context switching to be slow (which you probably will) then I blame whoever wrote ASP for doing such a poor job.

No one said anything about context switching beingslow, the issue was which technique was slower(or faster depending on how you're looking at it).

But you're right(CiberTHuG), it really depends on the situation(size of the page/script, expected number of page requests/sec, maintainability, etc). I use inline asp tags too, if the situation calls for it. Benchmarking your own pages is the only way to tell which method is best.

**CiberTHuG** · Dec 27th, 2001, 04:35 PM

Uhm... if you find context switching to be slow. That is the same as saying "if you find it to be slower than" whatever. There is no absolute measure of slow, so to use it as a reference implies you are comparing to something. I hope that makes sense.

**ubunreal69** · Dec 28th, 2001, 03:53 AM

Originally posted by Al Smith
[B]Hi,
Are there pro's or con's to either of the below?
One breaks out of asp to do the HTML the other Response.Writes the HTML.

Thanks,
Al.

well, i have to have a say on this subject. sorry.

1.) I think it doesnt really matter unless ur running a slow server and unless its battling under the workload then there isnt reallly that much to worry about.

2.) switching between ASP & HTML all the time makes things more confusing, keeping to biger chunks of the same language makes for easier modifying of code as needed (coding the page).

ME!

Red Rush-In · Dec 28th, 2001, 11:38 AM

First I'm going to say that the difference in peformance is almost unmentionable. That being said I think it is better to switch between the two and here is why.

1) Color Codeing I use HomeSite for development. By switching between the two it is much easier to view and maintain my code.

2) Working with a disign staff Lets face it, if you are going to be developing a profesional site your probably not going to be designing the page layouts. Where I work we have a seperate team of graphic designers and programmers. By breaking out between the HTML and ASP we don't step on each others feet. It wouldn't really be an issue if the code was written once and then you never had to go back to it. But, both the programmers and the designers are going to have to make changes to the pages periodicly.

And even when I'm developing an app for my own personal use I use switching becuase it is so much easier to maintain. I first create the app using all HTML so that I can get the layout finalized and then go back and make it function by adding the asp.

**Redth** · Dec 29th, 2001, 11:31 AM

well i haven't ever actually compared the two methods either, although unless you're running a massive server with that many requests to the page, it probably isn't going to make a big difference to the performance....

although... when the script is processed, it goes through all the asp tags and processes them... it doesn't touch the html does it? if this is the case, using as much html as possible everywhere would be quicker, no?

Response.Write is sent through the ASP processor and the processor spits out what's in the Response.Write.... as opposed to just sending the html that's in the page, untouched....

am i right in thinking here? this is just an educated guess....

either way though, the difference probably isn't that overwhelming...

and if the difference is soooo subtle... i'd rather use inline code.... editting the html of the page itself, i find is easier to do by leaving it as html, and not putting it into asp Response.Writes... easier to read and easier to change in frontpage (or whatever your weapon of choice is)...

Thread: To Response.Write or Not to Response.Write

Thread Tools

Display

To Response.Write or Not to Response.Write

Re: To Response.Write or Not to Response.Write

Posting Permissions