ASP Speed Tweaking

Printable View

Jan 23rd, 2001, 01:55 PM
JoshT

Is there any advantage to doing the bulk of the processing before the <html> tag, and just using <%= %> a couple of times. How about if I would edit the unused constants out of my ADOVBS.INC file?

Any other tips?

Thanks,
Josh
Jan 23rd, 2001, 04:36 PM
G.Kumaraguru

U are right...

If the Processing is done Separately...There is no need for the Processor to Jump from scripting mode to html mode to and fro...

'I don't use Adovbs.inc... I just copy those required constants in my asp page.
Jan 23rd, 2001, 04:48 PM

MSDN has some great articles on this topic.

http://msdn.microsoft.com/workshop/s...sp/maxperf.asp

http://msdn.microsoft.com/workshop/s...er03272000.asp

My best suggestion is do processing in COM components, they are faster by a factor of hundreds because they're already compiled.
Jan 23rd, 2001, 06:31 PM

Hangon...what's this about the server switching from html to asp mode?

It's my understanding that when an ASP page is requested, the server farms the request out to the ASP engine which processes ALL the vbscript there and then. It ignores all html markup. Once it has replaced everything within <% %> tags with the code's results it sends the page back to the server which passes in on to the browser as the reply to the original request. NOTHING ON THE SERVER EVER PROCESSES ANY HTML. Only the browser actually processes the html.

Assuming what I have said above is correct then I see no advantage to putting all your vbscript before your html, other than making easier to understand.

As for the adovbs.inc file then only using the constants you actually use will marginally improve performance - less for the asp engine to process but I can't imagine there is much speed to be gained. Other factors like inefficient coding and the time taken to connect to other servers will have a much bigger impact on the speed of your pages.
Jan 24th, 2001, 07:49 AM
JoshT

Thanks,

I was thinking about going to COM, but since it's an Intranet server, traffic's not that high and COM DLLs will be a heck of a lot harder for someone else to maintain later.

As far as switching between HTML and ASP, I thought that the server has to parse the script for #includes before sending it to the ASP engine, or does the ASP engine handle that as well?

And since you can do things like

Code:

<% If str = "Good" then %> <p>Good <% Else %> <p>Bad <% End If %>

The ASP engine seems to do a little more with the HTML than just replace <% %> tags.

Josh
Jan 24th, 2001, 08:04 AM

Sorry...I simplified it a little to much...in my explanation before the asp engine would treat

Code:

<% if ... then %> <h1>...</h1> <% else %> <h2>...</h2> <% end if %>

as one asp block to be replaced by either "<h1>...</h1>" or "<h2>...</h2>" depending on the result of the if statement. The html itself isn't processed on the server machine...the most that happens to it is that some (like you have mentioned) might be cut out before the browser receives the page.

And yes the web server does process all SSI statements before it gives the page to the asp engine, however SSI statements are not HTML so what I said before is correct.
Jan 24th, 2001, 11:19 AM
Clunietp

Actually every time you switch between ASP tags (<% %>) and HTML tags, something called context switching occurs. This is inefficient. Block together as much ASP code as possible in order to avoid context switching.

From what I understand, your web server must switch between the ASP.DLL thread and INETINFO thread (or something like that) when it changes the tag type

AWESOME, MUST-READ article on ASP performance here
http://www.asptoday.com/articles/20000113.htm
Jan 24th, 2001, 11:23 AM

That's daft that. Tell Microsoft to get their act together an do it properly. The server doesn't need to process the html so why pass it back to the web server every time it spots html tags...oly to be passed back again when asp code is found?
Jan 24th, 2001, 11:26 AM
Clunietp

Don't quote me on that Matthew, I was only speculating on what happens. I do know for certain though that context switching occurs, so that was my logical guess. Ya think?
Jan 24th, 2001, 11:28 AM
Clunietp

Maybe it's between the script engine and ASP.....yeah, that makes more sense......
Jan 24th, 2001, 11:45 AM

Mmm...it does seem silly, pointless and inefficient.
I can't see that Microsoft (aside from all their shortcomings) would be that stupid.

Aside from perhaps not devoting enough time to debugging, Microsoft's software is usually pretty good - bugs aside it's normally extremely functional, easy to use, looks professional and is pretty quick and efficient.

I find it very hard to belive that they would make such an inefficient a product to be used by so many programmers who could just as easily use php or perl or cold fusion or... or... or...
Jan 24th, 2001, 01:21 PM
JoshT

That's what I was wondering about in the first place. I suppose I'll put all the ASP together just because it looks better that way. Now, if I would put VBScript, JScript, and PerlScript all on the same page, and mix in lots of <% %> and <object runat=server> tags, I wonder what would happen...

Josh
Jan 24th, 2001, 06:11 PM

You'd be declared criminally insane and carted off to the funny farm. :D

Also how do you expect to get the server to send the page to all three engines (without writing your own isapi or cgi filter that farms it out that is)?
Jan 25th, 2001, 11:36 AM
Serge

I want to add something to this thread. If you want your ASP code to be as fast as possible, then you shouldn't mix HTML with ASP Script. According to Microsoft if you use pure ASP, it would be a lot faster (around 2.5 - 3 times faster) then mixing it with HTML. Here is an example:

This would be slower:

Code:

<Select name lstMyList size=10> <%Do Unil rs.EOF%> <option><%=rs("MyValue")%></option> <%rs.MoveNext%> <%Loop%> </Select>

then this:

Code:

<% Response.Write "<Select name lstMyList size=10>" Do Until rs.EOF Response.Write "<option>" & rs("MyValue") & "</option>" rs.MoveNext Loop Response.Write "</Select>" %>

Just my $0.02
Jan 25th, 2001, 12:28 PM

Quite possibly true but it's harder to read (IMHO of course).

Also I think that in the majority of cases it wouldn't make all that much difference. Inefficient coding will have a bigger impact on the speed of the page.
Jan 25th, 2001, 12:41 PM
G.Kumaraguru

Mathew...

You can Change Language by using Script tags

<SCRIPT LANGUAGE="VBScript" RUNAT="Server">

</SCRIPT>

<SCRIPT LANGUAGE="JScript" RUNAT="Server">

</SCRIPT>

on the same page...

But i never tried it... and I won't...
Jan 25th, 2001, 12:46 PM

{LOOKING MILDLY IMPRESSED THEN VERY QUICKLY BORED}

Mmmm...fair 'nuff.
Jan 25th, 2001, 01:31 PM
JoshT

Serge, I would end up doing something like:

Code:

<% Dim out out = out & "<Select name lstMyList size=10>" Do Until rs.EOF out = out & "<option>" & rs("MyValue") & "</option>" rs.MoveNext Loop out = out & "</Select>" %> <%= out %>

Any benefits?

Thanks,
Josh
Jan 25th, 2001, 01:47 PM
Serge

The benefit is Easier to read and probably would be a bit faster since you're writing it only once.

:)
Jan 25th, 2001, 11:20 PM
Clunietp

In case you guys still care:

Serge's method is faster as the Response.Write just adds the string to the end of the output buffer. When you append strings to strings in VB/VBScript the operation is comparatively slow

Benchmarks here on that and other great stuff
http://www.asptoday.com/articles/20000426.htm
Jan 26th, 2001, 04:00 AM

Everybody prepare to be amazed, look at this, no loop required!

Try the ADO getstring method.

after retrieving recordset do this

Code:

str = "<option value =" & rs.getstring(,,">","</option><option value=")

then in the html

Code:

<select name="select"> <%=str%> </select>
Jan 26th, 2001, 10:19 AM
Clunietp

I like it! You can do the same thing with </TD><TD> tags as well to create a basic table

To further optimize your page time, remove the </option> from the string -- browsers today don't require this tag and you can save yourself 9 bytes per item :)