«

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

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

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" 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

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 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
>
>
>.
>

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" <> wrote in message
news:...
> 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

"Tamara" <> wrote in message
news:02b701c37193$fdf021d0$...

>> 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

That's a good link Bob.

Takes a bit of reading but very 'enlightening'!

Thanks


"Bob Barrows" <> wrote in message
news:u%...
> 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
>
>