Casey wrote: On a separate note, jumping in and out of VBScript causes system slowdown, and in the long run you'll have better performance if you were to do something like this:
Perry (my alter-ego <grin>) responded: Hmmmm. Not to argue (I'm way too green at asp) but I was under the impression that dropping out of asp to implement standard html was the preferred method. You don't have to write line after line of "Response.write()". What information are you basing your statement on? Casey again: I first heard this theory from Greg C. on this list. Is he still around? Not seen a post from him in a long while. But since then I've had it confirmed by several co-workers as well. Yes, writing line after line of response.write is a task, but the resulting ASP is cleaner and faster. Then JR spoke: dropping in and out of ASP to static HTML is referred to as context switching. There are two reasons to avoid excessive context switching: performance and readability. First, performance. [snip of example] If you're not developing web pages for at least couple hundred users, it really won't make a lot of difference. Plus, the new ASP 3.0 engine and Windows 2000 are more efficient at handling context switches, so performance on that platform takes very minimal hits, except at extremely high usage/switching rates. But you also have readability and maintenance. Switching in and out of HTML/ASP isn't all that easy on human eyes, either. The more <%'s and %>'s there are in a script, the more likely you are to miss one or double up on one. Another thing, having static HTML blocks in your code means that a lot of white space (tabs and spaces) get sent with your page. using response.write doesn't send extra white space. IOW, instead of sending [tab][tab][tab][tab]<tr>[crlf] it only sends the <tr> ... saves 6 characters. The best compromise, I think, is to keep blocks together as much as possible. Don't switch every other line. There is one guy who publishes as site that uses an out() function to save typing response.write. I think that's just as bad, since you're calling a function every time. Myself personally, I context switch frequently during dev and debug, and then go back and wrap as much as possible in response.write's. Tim adds: This has been a topic I'm interested in, also. Developing a new site or app with is easier if you do a lot of context switching - it's easier to see what code is doing what, particularly if you're using an IDE of some sort. My approach is the same as JR's - develop and debug using a lot of switching, then go back and add Response.Writes to "block up" the code - reduce the switches to perhaps 5 or 10 per page or less. Some pages I completely write with Response.Writes (the menu system of our website, for example) just because I want it running as fast as possible. I also take the time to go back and View Source from the browser after I've converted to Response.Writes, just to make sure the HTML is getting indented nicely and looks good. I am different than JR in the fact that I have the ASP kick out the extra whitespace to retain the HTML formatting - it's one more way to make debugging easier on myself. A friend of mine looked at this issue pretty hard a few months ago, and came to the conclusion that even though context switching slows down a page, apparently using Response.Writes also takes a lot of time - almost as much as a switch would have taken. In his opinion it wasn't worth worrying about context switching unless you had a page coded and debugged pretty solidly and then converted the whole thing to Response.Writes, in which case of course it gets pretty hard to debug, particularly if you are (like me) sometimes cranking out client-side Javascript using Response.Writes. :-) Using an out() function probably just negates the whole idea of using Response.Write for speed. It would be used simply for convenience, I think, and you're only saving a few characters of typing. While I always try to use the most efficient code I am capable of producing, our site doesn't get hit hard at all and it's never an issue. It seems to me if you really needed the speed you'd go with .NET (which I have yet to learn) since the ASP gets compiled and supposedly runs 50x - 100x faster than "classic" ASP. One day I will go there, but the learning curve seems a little steep and I can't find the time to dive in because all the other projects are "need it yesterday!". :-) I might add that one reason I haven't started using .NET yet is that I want to learn it *properly* - move my head more into an object-oriented frame of mind rather than just converting old ASP into VB.NET. I don't really think in terms of objects at the present - it's going to be an adjustment. Most of what I do is on such small scales that building objects takes longer than just cranking out procedural code to do the same thing. Never could get my head around the "Hello world" object. :-) Tim ___________________________ Tim Furry Web Developer Foulston Siefkin LLP ____ • The WDVL Discussion List from WDVL.COM • ____ To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED] Send Your Posts To: [EMAIL PROTECTED] To change subscription settings to the wdvltalk digest version: http://wdvl.internet.com/WDVL/Forum/#sub ________________ http://www.wdvl.com _______________________ You are currently subscribed to wdvltalk as: archive@jab.org To unsubscribe send a blank email to [EMAIL PROTECTED]
