| Author |
 Topic  |
|
h20
Starting Member
39 Posts |
 Posted - 16 July 2001 : 18:04:47
|
Which one performs better? A while back someoone sommented on this... I cannot remember what the answer was whough.
|
|
|
Id
Junior Member
USA
129 Posts |
Posted - 16 July 2001 : 18:08:29
|
with response.Write you can write out multiple lines of code i.e.
<%
response.write "This is a test string that you may" &_
" at some point use"
%>
Where as with <%= %> you can only right out what's on one line, which is really only useful for writing out variables, where as with Response.Write, you can right out strings and the like when needed
|
 |
|
|
Doug G
Support Moderator
USA
6493 Posts |
Posted - 16 July 2001 : 18:27:04
|
<% %> are delimiters that indicate server-side script. Whatever is contained within <% %> tags is processed on the web server.
You could code a page like
<HTML>
<BODY>
This is a <%response.write "test"%>
</BODY>
</HTML>
======
Doug G
====== |
|
|
|
Dan Martin
Average Member
USA
528 Posts |
Posted - 17 July 2001 : 10:59:12
|
Well, I remember people saying that this is slow:
<% If a = b Then %>
<i>A equals B</i>
This is slower code
<% end If %>
But, <%=something%> is no different than <%Response.Write(something)%>
In fact, if you ever get an error in that line, you will see it replaces the "=" with Response.write.
In the end, the fast computers of today run either at a pretty good clip. I usually code the way that looks the best, and only worry more about memory leaks and such (those are what really kill performance). If you have enough users, perhaps the .004 of a second you save is important.
-Dan |
|
|
|
davemaxwell
Access 2000 Support Moderator
USA
3020 Posts |
Posted - 17 July 2001 : 12:47:49
|
quote:
Well, I remember people saying that this is slow:
<% If a = b Then %>
<i>A equals B</i>
This is slower code
<% end If %>
But, <%=something%> is no different than <%Response.Write(something)%>
In fact, if you ever get an error in that line, you will see it replaces the "=" with Response.write.
True this is slower:
<% If a = b Then %>
<i>A equals B</i>
This is slower code
<% end If %>
This is the better way:
<% If a = b Then
Response.Write "<i>A equals B</i>" & vbCrLf & _
"This is slower code"
end If %>
The speed drain comes from switching from ASP to HTML and back again.
Dave Maxwell
--------------
Proud to be a "World Class" Knucklehead |
|
|
|
Doug G
Support Moderator
USA
6493 Posts |
Posted - 17 July 2001 : 15:48:01
|
IMHO, in most normal pages you'll never notice the difference in speed between different coding methods. The overhead for context switching isn't all that great.
FWIW, most of the code I write is completely VBS using response.write, hardly any HTML sneaks in. I tend to use subs, functions and classes heavily.
======
Doug G
====== |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 17 July 2001 : 16:43:24
|
quote:
IMHO, in most normal pages you'll never notice the difference in speed between different coding methods.
======
Doug G
======
A couple of things:
1) If you run the same code in a loop (say 1000 times) it will make a difference.
2) You will not see the html part in a preview window if you use response.write's. Thus, change to response.write's, after the page design is OK.
3) Some editors (like Dereamweaver) will suffer in html code coloring if you mix them. This is exactly the case if you include the inc_functions.asp in a page (this file has a couple of subs without response.write's). I changed them to response.write's to be able to see the coloring in the main document. (Actually this is a request, and if you don't mind, I want to change them while I'm doing the internationalization)
Cheers.
Think Pink |
|
|
|
h20
Starting Member
39 Posts |
Posted - 17 July 2001 : 17:09:47
|
Thanks for the replies everyone. Obviously there is some additional server overhead when you go in and out of ASP / html. Reason beeing the IIS has to load the compiler for whatever language you are using... this is especially the case for non-standard ASP languages i.e. PERL.
I would say that if the page was on either the middle or server tier then using the Response object would be the better approach. Client tiered pages that may place the date or somthing of that nature could use the <%=%> approach... just for convenience and aesthetic reasons.
Again, thanks
Scott
|
|
|
|
Doug G
Support Moderator
USA
6493 Posts |
Posted - 17 July 2001 : 20:16:51
|
quote:
1) If you run the same code in a loop (say 1000 times) it will make a difference.
A loop that executes 1000 times and has inner code that outputs HTML using both response.write and HTML will be a very unique page, I think. :)
As far as loading interpreters for different scripting languages on an asp page, that happens only once per page no matter how many times you switch in & out of <% %> tags. A better performance tip is to make sure you set the default scripting language for pages that don't use the server default, and don't specify the default language on your page if you know it's the default language for the server (i.e., VBScript for nearly all IIS servers).
======
Doug G
====== |
|
|
|
mrWize
deleted
119 Posts |
Posted - 19 July 2001 : 18:54:36
|
And the most dramatic performence bost is to set buffering to true, either it is set on the server, win2k/IIS 5 has it as default but NT 4/IIS 4.x has buffering of in an default installation.
Test this approach on top ov every .asp page you script:
<%
Option Explicit
Response.Buffer = TRUE
%>
When using Option Explicit YOU have to DIM all variables, and that makes an speed change too
cya,
mrWize
|
|
|
|
mrWize
deleted
119 Posts |
Posted - 19 July 2001 : 18:59:35
|
This is good:
<%
Response.Write "This is a line " & _
"and here it will continue"
%>
This is Bad:
REsponse.Write "This is a line "
Response.Write "and here it will continue"
<%
asp code
%>
this is a line
and here it will continue
<%
more asp code
%>
AND
Good:
strSQL = "SELECT SOME_FIELD, ANOTHER_FIELD " & _
"FROM SOME_TABLE " & _
"WHERE THIRD_FIELD = " & intSomeVariable & "_
" ORDER BY SOME_FIELD ASC"
Bad
strSQL = "SELECT SOME_FIELD, ANOTHER_FIELD "
strSQL = strSQL & "FROM SOME_TABLE "
strSQL = strSQL & "WHERE THIRD_FIELD = " & intSomeVariable
strSQL = strSQL & " ORDER BY SOME_FIELD ASC"
especially if You build variabels like this in a loop.
cya,
PatrikB
|
|
|
|
mrWize
deleted
119 Posts |
Posted - 19 July 2001 : 19:04:13
|
Forgot one more thing.
When You have to get anything from the Request object It´s better to get it before You open any connections to a database, especially when using cookies.
i.e:
strCookieValue = Request.Cookies("CookieName")("CookieKey")
then open database and instead of going to the request object You "scream" for the variable, strCookieValue, instead.
cya,
mrWize
|
|
|
|
Dan Martin
Average Member
USA
528 Posts |
Posted - 20 July 2001 : 14:18:25
|
quote:
Good:
strSQL = "SELECT SOME_FIELD, ANOTHER_FIELD " & _
"FROM SOME_TABLE " & _
"WHERE THIRD_FIELD = " & intSomeVariable & "_
" ORDER BY SOME_FIELD ASC"
If I'm doing my math right, that's 1 RAM access.
quote:
Bad
strSQL = "SELECT SOME_FIELD, ANOTHER_FIELD "
strSQL = strSQL & "FROM SOME_TABLE "
strSQL = strSQL & "WHERE THIRD_FIELD = " & intSomeVariable
strSQL = strSQL & " ORDER BY SOME_FIELD ASC"
That's 4 RAM accesses.
You'd have to loop a LOT of times to notice that at all. Pretty trivial when memory is running at 133,000,000 cycles per second (PC133 memory), or even 266,000,000 for (PC2100 DDR memory).
So, we are talking about 1/133,000,000 of a second for the "Good" method, and 4/133,000,000 for the "Bad" method.
Or change that to 100,000,000 if you purchased the cheap memory. 
But, I'm no optimization guru, so maybe I'm missing something.
-Dan
Edited by - Dan Martin on 20 July 2001 14:29:26
Edited by - Dan Martin on 20 July 2001 14:30:06 |
|
|
|
Doug G
Support Moderator
USA
6493 Posts |
Posted - 20 July 2001 : 15:47:27
|
quote:
That's 4 RAM accesses
It will be a lot, lot more than 1 or 4 ram accesses. Building strings by concatenation is somewhat more computer intensive than just using line extensions. However, it is so common for me to have computations and branches when I need to build a string I usually use the plan b above.
There is an excellent reference for optimizing asp code at this link
http://msdn.microsoft.com/workshop/server/asp/ASPtips.asp
======
Doug G
====== |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 20 July 2001 : 16:07:20
|
quote:
It will be a lot, lot more than 1 or 4 ram accesses.
Yes much and much. There must be an interpreter behind it, taking all the strings, parsing them into tokens, making calls to OS subroutines, sending messages, waiting for the result, etc. If you guys have taken cources on computer language/compiler design must know that.
Think Pink |
|
|
|
Id
Junior Member
USA
129 Posts |
Posted - 20 July 2001 : 16:52:53
|
I think what Dan's trying to say, is that on today's typical server machine you're not going to notice a difference between Method A for creating a query and Method B. Now on a benchmark test, there would be a few milliseconds of difference, but to the normal viewer, they won't know any better, and that's what matters
|
|
|
|
Topic |
|
Topic Locked
