As I recollect, IIS 4.0 would "compile" an ASP page
into Visual Basic P-code.  Much like JSP on the
popular servers, like WebLogic.

Then, when you reboot the IIS server (or the machine...
whichever comes first :-) the first time the page was
accessed, it would be re-compiled into P-code.

<NOSTALGIA>
Funny.  I started programming with BASIC on a PDP-8
in college.  After 20 years, I found myself programming in
Visual Basic (A.K.A.; VBA, ASP, VBS) on a DEC Alpha!!

I gotta hand it to B*ll Gates -- the guy has taken over
the world with a 3rd rate language I picked up on a lark
in Junior College...
</NOSTALGIA>

-----Original Message-----
From: A mailing list about Java Server Pages specification and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of Jesse Clark
Sent: Sunday, February 13, 2000 2:21 PM
To: [EMAIL PROTECTED]
Subject: Re: ASP vs JSP


?D ??? ???  ?" #*? ???
??P
??????? ??
?
??
??? ??
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

>
>> ASP scripts get interpretted everytime a user requests the .asp page.
>
> Ummm, do you really think the people developing the ASP engine at MS are
> quite that dumb?  A compiled ASP page is cached in memory, and I'm sure
> THAT is why speed is comparable to JSP.


I was curious to know in caching/page translation was handled in ASP
compared to JSP. So, I pulled up the Microsoft Developer Network
(http://msdn.microsoft.com) and did some looking. On the "ASP A to Z" page
they have a section on caching
(http://msdn.microsoft.com/workshop/server/feature/cache.asp).

However, here they are discussing "output caching" vs. "input caching" where
"output caching" is storing "transformed output" (the results of a processed
script FUNCTION that returns some data, not the whole page itself), and
"input caching" is the creation of a custom recordset in the VBScript that
is accessed by an asp page; this record set is then stored in memory so that
it can be accessed by different asp pages that might return the content in
different formats for different users.

Unfortunately, the article doesn't cover whether the .asp page itself or the
VBScripts that the asp accesses are cached or not. From what I can find from
Microsoft it doesn't appear that they are. Thus, everytime that a request
comes in for an .asp page any variables created or connections accessed
therein or within the VBScripts(those without static content as above, read
Bean) that the page uses are going to have to be initialized everytime that
they are accessed.

The advantage that jsp would have then would be that after the initial call
to a page, the page and the beans or servlets that control or are accessed
by the jsp page, are stored in memory and all the space is already allocated
just waiting to be defined/filled with the required values.

I'm sure that this is probably a narrow perspective overview, (and possibly
wrong I've only researched it for 10 minutes...), and if there are any asp
converts lurking out there who could clarify more, I for one would like to
know as I often find myself having to give arguments for the use of jsp over
other dynamic content serving/distributed app solutions and would like to
know for sure how jsp stacks up speedwise.

_jesse


> Jason Boehle
> [EMAIL PROTECTED]
>
>
===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> FAQs on JSP can be found at:
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
>

===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
FAQs on JSP can be found at:
 http://java.sun.com/products/jsp/faq.html
 http://www.esperanto.org.nz/jsp/jspfaq.html

===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
 http://java.sun.com/products/jsp/faq.html
 http://www.esperanto.org.nz/jsp/jspfaq.html

Reply via email to