ASP code vs COM Components

[CJM]

I realise this question has come up in some form or other many times in the
past, but indulge me, please.

I've just been reviewing a COM component (VB6) that I wrote a while ago to
record when and where 404 errors occur; each error is logged in a DB along
with supporting information.

Looking at it now, I'm wondering why I chose a COM component rather than
just an ASP page. There is not that much code involved, so I could easily
have expanded the ASP page that calls the DLL to do the whole job....

COM Component:
Generally perform faster than an ASP page, but there is an overhead
associated with creating a new object in the calling ASP page, so more
suited to more intense apps that dont require user-interaction. Also keeps
code private of course.

ASP:
Keeping you code in an ASP page is often more efficient for smaller jobs,
where the cost of creating a COM object outweighs the potential performance
gain. Also prefered for tasks that require frequent user interaction. Code
remains public (to those who have access to server).

This is what prompted my question: At what point, does it become worthwhile
to go for a COM component as opposed to an ASP page? Is there that much
difference in it?

Are perceptions of the issues fairly accurate?

I've updated the DLL in question - it was a bit of a ball ache: modify code
& compile, reset IIS, then copy DLL to server and re-register. I know my DLL
in this example doesnt do much, and I'm certain that modifying and copying
ASP pages would be simple & efficient, but at what point does it pay to use
a DLL?

Thanks

Chris

[Bob Barrows]

CJM wrote:

COM Component:
Generally perform faster than an ASP page, but there is an overhead
associated with creating a new object in the calling ASP page, so more
suited to more intense apps that dont require user-interaction. Also
keeps code private of course.

No argument with the security factor. However, performance has been shown to
be better with straight ASP. See here:
http://msdn.microsoft.com/library/en...ocu2kbench.asp

[Michael D. Kersey]

Anthony J Biondo Jr wrote:

Hi Chris:

The way I look at it, if you have allot of processing and logic you need to
perform it should be done in COM, because of the sheer fact that each time a
person hits the page it does not need to be recompiled.
An ASP page is NOT recompiled every time a person hits it!

It is only compiled for the first request; thereafter the pre-compiled
pcode (bytecode) is cached in IIS memory so all subsequent requests can
be executed immediately. For a description of the compilation and
execution process see Appendix 3 of
http://www.microsoft.com/technet/tre...e/iis5tune.asp

To see a sample of the compiled bytecode see
http://groups.google.com/groups?q=+%...-pc.org&rnum=2
I guess everyone
has their own perception of what "allot of processing" would be. I know
that we use COM for the web where we expect allot of hits and have critical
functions that need to happen. User Authentication, Logging, Inquiries to
other data stores.

In the light of how IIS and ASP *really* work, your methodology should
be re-evaluated. COM components will enhance performance only if the
task is *highly* CPU-intensive. I/O bound tasks (e.g., "User
Authentication, Logging, Inquiries to other data stores") do not qualify
and will perform better when done in ASP script. Before components pay
off performance-wise, you must have a *lot* of compute-bound code:

"Rule of thumb: unless there are at least 100 lines of script and some
big loops in that script, it's probably not worth thinking about
translating that page into a component."
Alex Homer, Dave Sussman, Brian Francis
page 1042,
"Active Server Pages 3.0"
(Wrox Press Ltd., 1999)

See http://groups.google.com/groups?oi=d...m=an_558802478 for more
details.
Good Luck,
Michael D. Kersey

[Michael D. Kersey]

"Michael D. Kersey" wrote:
<snipped>

It is only compiled for the first request; thereafter the pre-compiled
pcode (bytecode) is cached in IIS memory so all subsequent requests can
be executed immediately. For a description of the compilation and
execution process see Appendix 3 of
http://www.microsoft.com/technet/tre...e/iis5tune.asp
Apologies, the above URL is unduly nested. The correct URL is
http://www.microsoft.com/technet/pro...asp?frame=true
Good Luck,
Michael D. Kersey

[Tamara]

Perfect example is when your dll implements business logic
needed on both Web server and application(non-Web) server.
You can not share your asp code between two.

Another case would be a number-crunching task that
consumes CPU cycles. You are better off with compiled
code.

ANother one: ASP does not (at least explicitly) support
data types. You do not want to deal with ASP when the data
type matters (calculations or conversions). It can play
nasty tricks on you unless you deeply understand the
underlying data types in ASP.

Last one: Use of 3-d party libraries. You might be better
of with a wrapper around the library for the above reason
of data conversions.

Good luck.
Makes no sense for a 3-liner.

-----Original Message-----
I realise this question has come up in some form or other many times in thepast, but indulge me, please.

I've just been reviewing a COM component (VB6) that I wrote a while ago torecord when and where 404 errors occur; each error is logged in a DB alongwith supporting information.

Looking at it now, I'm wondering why I chose a COM component rather thanjust an ASP page. There is not that much code involved, so I could easilyhave expanded the ASP page that calls the DLL to do the whole job....
COM Component:
Generally perform faster than an ASP page, but there is an overheadassociated with creating a new object in the calling ASP page, so moresuited to more intense apps that dont require user- interaction. Also keepscode private of course.

ASP:
Keeping you code in an ASP page is often more efficient for smaller jobs,where the cost of creating a COM object outweighs the potential performancegain. Also prefered for tasks that require frequent user interaction. Coderemains public (to those who have access to server).

This is what prompted my question: At what point, does it become worthwhileto go for a COM component as opposed to an ASP page? Is there that muchdifference in it?

Are perceptions of the issues fairly accurate?

I've updated the DLL in question - it was a bit of a ball ache: modify code& compile, reset IIS, then copy DLL to server and re- register. I know my DLLin this example doesnt do much, and I'm certain that modifying and copyingASP pages would be simple & efficient, but at what point does it pay to usea DLL?

Thanks

Chris
.

[CJM]

This is this is my understanding also...

And you have essentially provided a good rule of thumb:

If the task is CPU-intensive (eg > 100 lines of code) then a COM solution
may offer some benefits, otherwise, an ASP-only solution is likely to be the
best result.

...other conserations permitting....

It's what I suspected, but it's good to hear it again.

Thanks

"Michael D. Kersey" <md******@hal-pc.org> wrote in message
news:3F***************@hal-pc.org...

Anthony J Biondo Jr wrote:

Hi Chris:

The way I look at it, if you have allot of processing and logic you need to perform it should be done in COM, because of the sheer fact that each time a person hits the page it does not need to be recompiled.
An ASP page is NOT recompiled every time a person hits it!

It is only compiled for the first request; thereafter the pre-compiled
pcode (bytecode) is cached in IIS memory so all subsequent requests can
be executed immediately. For a description of the compilation and
execution process see Appendix 3 of

http://www.microsoft.com/technet/tre...e/iis5tune.asp
To see a sample of the compiled bytecode see
http://groups.google.com/groups?q=+%...-pc.org&rnum=2

I guess everyone
has their own perception of what "allot of processing" would be. I know
that we use COM for the web where we expect allot of hits and have critical functions that need to happen. User Authentication, Logging, Inquiries to other data stores.

In the light of how IIS and ASP *really* work, your methodology should
be re-evaluated. COM components will enhance performance only if the
task is *highly* CPU-intensive. I/O bound tasks (e.g., "User
Authentication, Logging, Inquiries to other data stores") do not qualify
and will perform better when done in ASP script. Before components pay
off performance-wise, you must have a *lot* of compute-bound code:

"Rule of thumb: unless there are at least 100 lines of script and some
big loops in that script, it's probably not worth thinking about
translating that page into a component."
Alex Homer, Dave Sussman, Brian Francis
page 1042,
"Active Server Pages 3.0"
(Wrox Press Ltd., 1999)

See http://groups.google.com/groups?oi=d...m=an_558802478 for more
details.
Good Luck,
Michael D. Kersey

[CJM]

"Tamara" <t_*****@yahoo.com> wrote in message
news:02****************************@phx.gbl...

ANother one: ASP does not (at least explicitly) support

data types. You do not want to deal with ASP when the data
type matters (calculations or conversions). It can play
nasty tricks on you unless you deeply understand the
underlying data types in ASP.

Last one: Use of 3-d party libraries. You might be better
of with a wrapper around the library for the above reason
of data conversions.

Yes, its a fair point about type-conversion...

Thanks

[CJM]

That's a good link Bob.

Takes a bit of reading but very 'enlightening'!

Thanks
"Bob Barrows" <re*******@yahoo.com> wrote in message
news:u%****************@TK2MSFTNGP10.phx.gbl...

CJM wrote:

COM Component:
Generally perform faster than an ASP page, but there is an overhead
associated with creating a new object in the calling ASP page, so more
suited to more intense apps that dont require user-interaction. Also
keeps code private of course.
No argument with the security factor. However, performance has been shown

to be better with straight ASP. See here:
http://msdn.microsoft.com/library/en...ocu2kbench.asp