Newbie The best and fastest way to get a recordset
![Juan T. Llibre [MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Juan T. Llibre [MVP]
After a long business trip, I'd like to take up this
thread again, as I feel that there's some inconsistencies
which need clearing up.
Comments inline...
>"Juan T. Llibre [MVP]" wrote:
>>
>> That all sounds fair and good but...
>>
>> Why is it that Microsoft insists that "componentizing"
>> is the way we achieve "scalability" and "efficiency" ?
Michael D. Kersey wrote :
>To increase revenue.
>And maybe a little to make it easier to maintain applications and
>control programmers during development in large projects.
>But mostly to increase revenue.
>Reason is, a more complex architecture
>a) requires additional training of programmers,
>b) requires additional purchase of software (need Visual Basic, Visual
>C++ and training in each),
>c) requires additional hardware (for developers) to develop,
>d) obfuscates the inherent problems in existing products,
>e) provides time for Microsoft to re-position to market changes,
>f) ties up developers in a way that prevents them from exploring other
>more reasonable non-Microsoft options that are clearly explainable,
>logically consistent, and more productive,
>f) creates FUD (fear, uncertainty, and doubt) in managers who *always*
>go after Silver Bullet solutions to assuage their information-processing
>fears.
It's amazing, Michael, for someone who claims to be against
"obfuscation", how many "obfuscating" concepts/buzzwords YOU use.
Do you REALLY think that developers and programmers
swallow anything Microsoft offers "hook, line and sinker" ?
Won't you give the millions of programmers
who use and write components SOME credit ?
re :
>> If scripts are faster, more scalable, than components,
>> why should we "componentize" ?
>
>Not for performance.
>For standardization, maintainability, encapsulation perhaps. But if you
>can do standardization and encapsulation in your database by using
>stored procedures, then components are not going to be very useful.
Only in a very limited manner ( when DATABASE access is considered
in isolation from all other factors ) could this be true.
re :
>> Something doesn't add up.
>
>Of course. For a long time you've been accepting claims based on
>authority(Microsoft's) alone, instead of *thinking* them through.
>Microsoft puts out a lot of information; most developers are kept
>"off-balance" just trying to digest the latest-and-greatest new thing
>from MS. Few have time to think about what they're told, to make sense
>of it, and look for inconsistencies. e.g., just try to get a clear
>explanation of Microsoft's various threading models (my favorite is
>"apartment" threading!-))
That's a bold statement to make...and an unwarranted assumption.
If the amount of information to be absorbed in order to stay up to date
befuddles you, please don't assume that the same happens to others.
re :
>> It would seem to me that "compiled Visual C++ code in a DLL"
>> would always outperform "compiled" VBScript code.
>
>But it is not necessarily so. It depends on how well the compilers are
>written. E.g., IBM's Fortran compiler would generate code that ran
>faster than IBM's C compiler, because it had been more fully optimized
>over its long history. This is probably true of Microsoft's products as
>well.
>In any case, the relative speed of Visual C++ vs VBscript doesn't really
>enter this argument until you have extremely complex business rules (as
>shown in another post on this thread). Even then it is usually not
>significant.
Please tell me, Michael, WHERE does VBScript code, in ASP scripts, get
"compiled" ?
Where is the "compiler" which IIS would need to call to "compile" VBScript ?
ASP scripts are NOT "compiled" at any time, at least if by "compiling"
you mean the generation of machine or P-code.
re :
>> I don't think that scripts are "compiled", either.
>> All that I think happens is that a copy of the
>> script is placed in memory, the first time it's run.
>> That's hardly a "compilation".
>> The scripts still have to be parsed and interpreted.
>
>See the URL
>http://msdn.microsoft.com/library/psdk/iisref/apro8wv9.htm
>wherein is the explanatory text
>> "AspScriptFileCacheSize
>> This is preliminary documentation for IIS 5.0 and is subject to change.
>> This property specifies the number of *precompiled* script files
>to cache...."
>Note that this property has been available (as SCRIPTFILECACHESIZE)
>since at least IIS3. See also SCRIPTFILECACHETTL, another related
>setting.
But...is "pre-compiling" the same as "compiling" ?
Doesn't "pre-compiling" just mean syntax-checking and placing a copy in
memory ?
Only AFTER that, if the syntax pans out...would code be "compiled",
and ONLY if a COMPILER is executed...to actually COMPILE the code.
re :
>Further, see your own post on Deja,
>http://x23.deja.com/getdoc.xp?AN=356611179&CONTEXT=943042142.193108
>3923&hitnum=4
>
>where you mistakenly refer to the settings above and to the scripts
>cached as being source. You have been aware of the settings for
>SCRIPTFILECACHESIZE and AspScriptFileCacheSize but were unaware of their
>full implications. This explains your surprise.
"Mistakenly" ? "unaware of their full implications" ?
You must have misread my posting.
Let me quote myself :
--------------------------------
In a sense, ALL scripts are 'compiled'...in a very general sense
of the word. I suspect the intended meaning is 'compiled to memory'.
I suppose that could simply be called 'caching',
but this may be a question for semantic analysis.
Once in memory, upon the next call,
1) ASP verifies that no changes have taken place
in, already-called, scripts or global.asa.
If no changes have taken place,
2) the file gets read from memory
if sufficient memory has been allocated in ScriptFileCacheSize
If ASP detects a change in a script, or global.asa, then
3) the file gets 're-compiled' to MEMORY,
and the process repeats itself.
--------------------------------------------
I don't believe that those statements are inconsistent
with what I have been trying to explain to you.
This may come as a surprise to you.
It does NOT come as a surprise to me ( I love understating points...)
re :
>Scripts are parsed and code generated from them("precompiled") when the
>script is first loaded by IIS.
NO !
Code is NOT generated from scripts when run.
Once again, to generate code : a COMPILER would have to intervene.
No compiler is included with IIS.
Neither VBScript.dll nor JScript.dll can compile code.
I may be wrong ( and I'd love to see somebody prove
me wrong, since I'd learn something in the process ),
but I believe that the "pre-compiling" which the documentation
refers to ( very sparsely, indeed ) is simply syntax-checking
followed by placing of a full copy of the script in memory ( caching ).
NO code-generation from syntax-checking parsing occurs.
re :
>Thereafter the "precompiled" code is
>cached until unloaded (until it times out - see SCRIPTFILECACHETTL
>setting). I'm sure you've seen the difference between compile-time error
>messages and run-time error messages.
Again, no compiler is called...so no compilation can occur.
re :
>Now I don't know if the generated code is true machine code (I doubt it)
>or "P-code" (most likely), because Microsoft has both technologies in
>their products. For example, Visual Basic can generate to native machine
>code or to P-code.
I'd love for you to point out to me which compiler generates the "P-code"
whioch you say is generated from scripts.
re :
>> But what if you include the rendering code in the DLL ?
>> Wouldn't that be faster than parsing a long script ?
>
>I don't know what you are speaking of when you say "rendering code".
Rendering = HTML rendering
Tables, columns, paragraphs, fonts, etc.
THAT can't happen inside the database engine.
re :
>> IOW, in a strict sense, you may be ( or are ) right but,
>> from a more complete point of view, components will outperform scripts.
>No, you're accepting *argumentum ad authoritatem* here. Think for
>yourself. Don't accept confused arguments from marketing promoters. My
>simple argument stands.
You must have a strong sense of self-righteousness to tell me
that I should not accept *argumentum ad authoritatem* while,
at the same time, that's exactly the same type of argument
I'm getting from you.
And you have a lot of gall to tell me to "think for myself".
You'd do well to take your own advice.
You have NOT proven your point, and are sidetracking the issue
by trying to inject dubious, irrelevant, logic into the thread.
"marketing promoters" ?
What are you "promoting" with this type of argument ?
Could it be that YOU are "lapping up" arguments which simply,
instead of examining them, you've accepted without thinking them out ?
re :
>> You can't isolate the running of a stored
>> procedure from the rest of an IIS Application.
>Certainly I can. The stored procedure runs in a separate address space
>(that of the DBMS). It may be possible to run SQL Server in the same
>address space as IIS, but to do so would be foolhardy, because it would
>risk opening your database to serious corruption. And I doubt that doing
>so is possible at all with Oracle, for example.
And what happens with the REST of the IIS Application ?
You seem to have a single-mindedness which mistakenly
believes that IIS Applications are composed ONLY of database calls.
There's much more to IIS Applications than just serving data from DBMS's.
re :
>> The best way to write a more efficient IIS Application
>> is to throw as much code as you can into components.
>Maybe for maintenance, but not for performance.
>
>But I'm surprised to see you make this statement. In the face of a
>clear, logical argument, you have retreated to this stance without good
>reason. I believe you are confused. Think it through. And don't accept
>confused unclear marketing presentations as logical arguments.
Logic is in the mind of the beholder.
What seems perfectly logical to you, might not actually be so.
So, your only recourse is to throw mud at MY logic,
instead of trying to prove your point.
If you can just point out to me which compiler generates
the code which you say is "generated" by IIS from scripts,
I'll concede the whole argument.
I'm willing to admit I was confused...if you can PROVE me confused.
Just telling me that I am confused won't make me confused.
The question is : are you willing to be objective enough
to either PROVE me wrong...or see the light in my argument ?
regards,
Juan T. Llibre
Director, Computer Sciences School
Universidad Nacional Pedro Henríquez Ureña
Microsoft Internet Development MVP [IIS/ASP]
ASP Resource : http://asptracker.com/
=============================
Michael D. Kersey
> It's amazing, Michael, for someone who claims to be against
> "obfuscation", how many "obfuscating" concepts/buzzwords YOU use.
What did you find confusing? IMHO My statements were very simple and
clear.
This is just an "ad hominem" attack.
> Do you REALLY think that developers and programmers swallow anything Microsoft offers "hook,
line and sinker" ?
This is a "straw man" argument: I never said this.
But, since you ask: no, I don't think "that developers and programmers
swallow anything Microsoft offers". But I know from personal experience
that managers often do. And managers make the purchasing decisions.
> Won't you give the millions of programmers who use and write components SOME credit?
Another false "straw man" argument: I never said this. Shame on you for
trying to draw a line between me and other programmers who use and write
components: I am one of those programmers. I can't avoid using
components with ASP, But I do *minimize* my component usage because I
know that component creation and marshalling of data across component
boundaries requires considerable time and memory.
> re :
> >> If scripts are faster, more scalable, than components,
> >> why should we "componentize" ?
> >
> >Not for performance.
> >For standardization, maintainability, encapsulation perhaps. But if you
> >can do standardization and encapsulation in your database by using
> >stored procedures, then components are not going to be very useful.
>
> Only in a very limited manner ( when DATABASE access is considered
> in isolation from all other factors ) could this be true.
Yes, but that is exactly where this thread originated: the original
question asked by
steve hall <sh...@uaex.edu> was
> Is there a faster way to get a recordest than by calling a DLL?
I have provided him with the correct answer: execute a stored procedure.
> re :
> >> Something doesn't add up.
> >
> >Of course. For a long time you've been accepting claims based on
> >authority(Microsoft's) alone, instead of *thinking* them through.
> >Microsoft puts out a lot of information; most developers are kept
> >"off-balance" just trying to digest the latest-and-greatest new thing
> >from MS. Few have time to think about what they're told, to make sense
> >of it, and look for inconsistencies. e.g., just try to get a clear
> >explanation of Microsoft's various threading models (my favorite is
> >"apartment" threading!-))
>
> That's a bold statement to make...and an unwarranted assumption.
> If the amount of information to be absorbed in order to stay up to date
> befuddles you, please don't assume that the same happens to others.
Perhaps if you would divide your statement (and tell me which is "bold
statement" and which is "unwarranted assumption") then I might answer
this. OTOH probably not!-))
> re :
> >> It would seem to me that "compiled Visual C++ code in a DLL"
> >> would always outperform "compiled" VBScript code.
> >
> >But it is not necessarily so. It depends on how well the compilers are
> >written. E.g., IBM's Fortran compiler would generate code that ran
> >faster than IBM's C compiler, because it had been more fully optimized
> >over its long history. This is probably true of Microsoft's products as
> >well.
> >In any case, the relative speed of Visual C++ vs VBscript doesn't really
> >enter this argument until you have extremely complex business rules (as
> >shown in another post on this thread). Even then it is usually not
> >significant.
>
> Please tell me, Michael, WHERE does VBScript code, in ASP scripts, get
> "compiled" ?
> Where is the "compiler" which IIS would need to call to "compile" VBScript ?
> ASP scripts are NOT "compiled" at any time, at least if by "compiling"
> you mean the generation of machine or P-code.
I take Microsoft at their word. The term "precompiled script files" is
theirs.
If you are OTOH asking for my *opinion*, then my opinion is that
a) the compiler for VBScript is in VBScript.dll, the compiler for
JScript in JScript.dll, etc. These components are accessed by Asp.dll
which must oversee the compilation of mixed-language scripts,
b) the compiler parses the ASP page and builds at least two items:
1) a hashed symbol table of all variables and
2) compiled lines of P-codes with arguments
and that these constitute a "precompiled" script.
c) If errors occur during the initial compile phase, errors are output
and processing ceases,
d) If no errors are encountered, then the result of the compilation is
then cached and executed.
Inotherwords, IMO the source code is not re-interpreted from scratch on
each execution.
> re :
> >> I don't think that scripts are "compiled", either.
> >> All that I think happens is that a copy of the
> >> script is placed in memory, the first time it's run.
> >> That's hardly a "compilation".
> >> The scripts still have to be parsed and interpreted.
> >
> >See the URL
> >http://msdn.microsoft.com/library/psdk/iisref/apro8wv9.htm
> >wherein is the explanatory text
> >> "AspScriptFileCacheSize
> >> This is preliminary documentation for IIS 5.0 and is subject to change.
> >> This property specifies the number of *precompiled* script files
> >to cache...."
> >Note that this property has been available (as SCRIPTFILECACHESIZE)
> >since at least IIS3. See also SCRIPTFILECACHETTL, another related
> >setting.
> But...is "pre-compiling" the same as "compiling" ?
> Doesn't "pre-compiling" just mean syntax-checking and placing a copy in
> memory ?
> Only AFTER that, if the syntax pans out...would code be "compiled",
> and ONLY if a COMPILER is executed...to actually COMPILE the code.
The phrase "precompiled" is very clear. It means "already compiled". It
does not mean "something you do before you compile".
Your use of the term "compiled to memory" is unclear. Apparently it
includes a lexical scan/parse of the code.
What it appears you are saying is that
a) scripts are "compiled to memory" (whatever that is), a lexical
scan/parse performed and type-checking done,
b) If the "compile" is successful, then the scan/parse information
(symbol table and syntax tree) is thrown away,
c) after that, on every execution, the "compile" scan/parse is performed
again (rebuilding the program's symbol table and syntax tree each time)
and only then is the program executed.
At this point, any competent compiler/interpreter designer should be
rolling on the floor laughing. Reason is, the lexical scan/parse is
easily one of the most time-consuming operation of a
compiler/interpreter. To redo it each time would be an appalling waste
of both resources and a programming misjudgement of the first order.
>
> re :
> >Scripts are parsed and code generated from them("precompiled") when the
> >script is first loaded by IIS.
> NO !
> Code is NOT generated from scripts when run.
> Once again, to generate code : a COMPILER would have to intervene.
> No compiler is included with IIS.
> Neither VBScript.dll nor JScript.dll can compile code.
> I may be wrong ( and I'd love to see somebody prove
> me wrong, since I'd learn something in the process ),
> but I believe that the "pre-compiling" which the documentation
> refers to ( very sparsely, indeed ) is simply syntax-checking
> followed by placing of a full copy of the script in memory ( caching ).
> NO code-generation from syntax-checking parsing occurs.
Here's where we disagree.
I'm not willing to reverse-engineer VBScript.dll, ASP.dll, and
Scrrun.dll just to say "I told you so."
In fact, I think the burden of proof is on you to show that ASP works
other than as documented. Simply redefining the term "compile" is not
sufficient.
> re :
> >Thereafter the "precompiled" code is
> >cached until unloaded (until it times out - see SCRIPTFILECACHETTL
> >setting). I'm sure you've seen the difference between compile-time error
> >messages and run-time error messages.
> Again, no compiler is called...so no compilation can occur.
>
> re :
> >Now I don't know if the generated code is true machine code (I doubt it)
> >or "P-code" (most likely), because Microsoft has both technologies in
> >their products. For example, Visual Basic can generate to native machine
> >code or to P-code.
>
> I'd love for you to point out to me which compiler generates the "P-code"
> whioch you say is generated from scripts.
>
> re :
> >> But what if you include the rendering code in the DLL ?
> >> Wouldn't that be faster than parsing a long script ?
> >
> >I don't know what you are speaking of when you say "rendering code".
>
> Rendering = HTML rendering
>
> Tables, columns, paragraphs, fonts, etc.
> THAT can't happen inside the database engine.
Again, divide the question:
Question 1: The original question asked the fastest way to access the
database.
Answer: a stored procedure.
Question 2: Is the rendering code faster if done in a DLL?
Answer: only if the length of the rendering code is great enough to
overcome the time required to create the component that would do the
rendering. In most cases, there is insufficient code to offset the time
lost in object creation, deletion, and the marshalling of resources
across component boundaries.
Note that Question 2 is addressed by a separate answer (and a proof) by
me earlier in another thread of this same topic.
> re :
> >> IOW, in a strict sense, you may be ( or are ) right but,
> >> from a more complete point of view, components will outperform scripts.
> >No, you're accepting *argumentum ad authoritatem* here. Think for
> >yourself. Don't accept confused arguments from marketing promoters. My
> >simple argument stands.
>
> You must have a strong sense of self-righteousness to tell me
> that I should not accept *argumentum ad authoritatem* while,
> at the same time, that's exactly the same type of argument
> I'm getting from you.
> And you have a lot of gall to tell me to "think for myself".
> You'd do well to take your own advice.
This is an "argumentum ad hominem" - another personal attack.
I merely ask that people think about what is presented and try it out
themselves.
I do not claim any particular authority other than myself. I am not a
representative of Microsoft: I do not have "MVP", "MCSD", or any such
acronym after my name. I have bought and paid for every bit of software
that I own, both shareware and from Microsoft. I have never accepted
money, job, title, software, trip, or any good whatsoever for
expressing any opinion on this or other newsgroups or in any forum
whatsoever.
I call 'em as I see 'em.
> You have NOT proven your point, and are sidetracking the issue
> by trying to inject dubious, irrelevant, logic into the thread.
You, sir, are attempting to sidetrack the issue. I indeed *have* proven
that the anwer to the question "Is there a faster way to get a recordest
than by calling a DLL?" is "execute a stored procedure." I stand by my
answer.
And, whereas the question as to whether ASP script is compiled once only
or upon each execution is a sidetrack issue, it is one I willingly
engage in. And here again I stand by my contention: ASP scripts are
precompiled in the *full* sense of that word: I contend that the
precompiled script includes a symbol table and ready-to-execute P-code.
> "marketing promoters" ?
> What are you "promoting" with this type of argument ?
> Could it be that YOU are "lapping up" arguments which simply,
> instead of examining them, you've accepted without thinking them out?
No, not possible. These are my own ideas. And they're not for sale!-))
> re :
> >> You can't isolate the running of a stored
> >> procedure from the rest of an IIS Application.
> >Certainly I can. The stored procedure runs in a separate address space
> >(that of the DBMS). It may be possible to run SQL Server in the same
> >address space as IIS, but to do so would be foolhardy, because it would
> >risk opening your database to serious corruption. And I doubt that doing
> >so is possible at all with Oracle, for example.
> And what happens with the REST of the IIS Application ?
> You seem to have a single-mindedness which mistakenly
> believes that IIS Applications are composed ONLY of database calls.
> There's much more to IIS Applications than just serving data from DBMS's.
More ad-hominem attacks:
When faced with a complex system, such as a web server, I do try to
break the system into it's various pieces and examine each
independently. Many call it "divide-and-conquer". You may call it
"single-mindedness".
> re :
> >> The best way to write a more efficient IIS Application
> >> is to throw as much code as you can into components.
> >Maybe for maintenance, but not for performance.
> >
> >But I'm surprised to see you make this statement. In the face of a
> >clear, logical argument, you have retreated to this stance without good
> >reason. I believe you are confused. Think it through. And don't accept
> >confused unclear marketing presentations as logical arguments.
>
> Logic is in the mind of the beholder.
> What seems perfectly logical to you, might not actually be so.
> So, your only recourse is to throw mud at MY logic,
> instead of trying to prove your point.
More ad-hominem attacks.
I presented my ideas and now I'm getting insulted.
The content, length and vituperativeness of your statements does remind
me of something a great developer (Breck Carter) once told me:
"Arguing with people on newsgroups is like wrestling with a pig: the pig
enjoys it and, after awhile, you both start to look the same."
Juan T. Llibre [MVP]
Comments inline...
>-----Original Message-----
>From: Michael D. Kersey [mailto:mdke...@hal-pc.org]
>Sent: Monday, December 06, 1999 11:20 PM
>"Juan T. Llibre [MVP]" wrote:
>> It's amazing, Michael, for someone who claims to be against
>> "obfuscation", how many "obfuscating" concepts/buzzwords YOU use.
>
>What did you find confusing?
>IMHO My statements were very simple and clear.
I found nothing confusing.
I'll divide my answer into two parts.
This part will address the "ad hominem" issue,
and a couple of off-topic points introduced by you.
The next post, once those are clear, will address the tech issues.
re :
>This is just an "ad hominem" attack.
Michael,
I've -more than once- complimented you on the quality
of your posts to this, and other, newsgroups.
But every single comment which you have singled out
as "ad hominem" in this message has been in RESPONSE
to an "ad hominem" attack initiated by YOU.
It seems like you a doing a bit of projection,
in the psychological sense.
Let me quote a few of your unprovoked "ad hominem" attacks :
>For a long time you've been accepting claims based on
>authority(Microsoft's) alone, instead of *thinking* them through.
>Think for yourself.
>Don't accept confused arguments from marketing promoters.
>In the face of a clear, logical argument,
>you have retreated to this stance without good reason.
>I believe you are confused. Think it through. And don't accept
>confused unclear marketing presentations as logical arguments.
>I do not have "MVP", "MCSD", or any such acronym after my name.
>I have bought and paid for every bit of software that I own.
>I have never accepted money, job, title, software, trip, or any good
>whatsoever for expressing any opinion on this or other newsgroups.
None of those comments are relevant to any technical point
in the thread, unless you want to include some sort of
"Microsoft marketing ploy" as an argument.
To continue would be tiresome.
In any case, it's clear that you regularly make statements
that belittle whomever takes an opposing point of view,
but resent it when those belittling arguments are pointed out.
The worst part is that you don't really need to do that.
Your level of knowledge is quite impressive,
and you don't need to resort to that type of logic.
re :
>> Do you REALLY think that developers and programmers swallow
>anything Microsoft offers "hook, line and sinker" ?
>
>This is a "straw man" argument: I never said this.
But it is NOT a "straw man argument".
Read what you wrote :
>most developers are kept "off-balance" just trying to digest
>the latest-and-greatest new thing from MS. Few have time to
>think about what they're told, to make sense of it, and look
>for inconsistencies.
...and when I wrote :
> The best way to write a more efficient IIS Application
> is to throw as much code as you can into components.
...you replied :
>don't accept confused unclear marketing presentations as logical arguments.
Michael, you have to separate your mistrust
of Microsoft from your technical arguments.
Too often, I've read posts of yours which introduce an
anti-Microsoft stance camouflaged as a technical point.
It's a bad habit...and an unneeded one, as I've already pointed out.
re :
>> Do you REALLY think that developers and programmers
>> swallow anything Microsoft offers "hook, line and sinker" ?
>Another false "straw man" argument: I never said this.
Not according to the quote above.
Let me quote it again :
>most developers are kept "off-balance" just trying to digest
>the latest-and-greatest new thing from MS. Few have time to
>think about what they're told, to make sense of it, and look
>for inconsistencies.
I don't think that it's unreasonable to read that statement as :
"I have found inconsistencies which most developers don't have the time to
find".
Furthermore, that statement also implies that you've had the
"time to think" about what you've been "told" while most
programmers haven't had that opportunity...and that you've
had the time to "make sense of it" while most programmers
haven't been able to do that.
Yet, after making that statement,
you reply that I'm using "straw man" arguments.
A clear case of projection.
re :
>Shame on you for trying to draw a line between me
and other programmers who use and write components.
Here's a very interesting case in point.
I point out an inconsistency.
You reply with a personal attack.
I can't possibly read "shame on you" any other way.
re :
You ...
> >No, you're accepting *argumentum ad authoritatem* here. Think for
> >yourself. Don't accept confused arguments from marketing promoters. My
> >simple argument stands.
Me....
> You must have a strong sense of self-righteousness to tell me
> that I should not accept *argumentum ad authoritatem* while,
> at the same time, that's exactly the same type of argument
> I'm getting from you.
>> And you have a lot of gall to tell me to "think for myself".
>> You'd do well to take your own advice.
You...
>This is an "argumentum ad hominem" - another personal attack.
My, my...the projection doesn't seem to ever end.
You tell me to "think for myself", i.e., trying to make some sort
of ventriloquist's dummy out of myself, and when I tell you that
I see through that...you accuse me of a "personal attack".
It seems that you think that it's OK when YOU make personal
attacks...but that when the attacked person objects...then that
person is attacking you.
Twisted logic, indeed.
re :
>I do not claim any particular authority other than myself. I am not a
>representative of Microsoft: I do not have "MVP", "MCSD", or any such
>acronym after my name. I have bought and paid for every bit of software
>that I own, both shareware and from Microsoft. I have never accepted
>money, job, title, software, trip, or any good whatsoever for
>expressing any opinion on this or other newsgroups or in any forum
>whatsoever.
>I call 'em as I see 'em.
Here's another pearl from you.
Via some strange sense of self-righteousness, you manage to imply
that MVP's ( particularly myself, I take it ) and MSCD's somehow are
less worthy than you are, because we have accepted some type of "graft"
from Microsoft and that our opinions are, therefore, biased.
But that is not an "ad hominem" attack, is it Michael ?
For the record, Michael :
1) I am not a representative of Microsoft.
2) Microsoft has NEVER paid me any money.
3) MVP is not a "title". It's an award for helping out in the
newsgroups IN MY FREE TIME out of my own FREE WILL.
4) Microsoft has NEVER paid for any trip for me as an MVP
5) I don't know what "any good whatsoever" means.
6) I also "call'em as I see 'em". When I write, it is I who is writing.
It is NOT, most definitely, Microsoft speaking.
I don't understand your need to make that type of statement,
unless you intentionally want to imply what is not.
re :
>No, not possible. These are my own ideas. And they're not for sale!-))
Another camouflaged "ad hominem" attack
( you love that buzz phrase, don't you ? )
You wouldn't be implying that MY ideas are for sale, would you ?
( Even if you included the smiley...)
re :
>More ad-hominem attacks.
>I presented my ideas and now I'm getting insulted.
>The content, length and vituperativeness of your statements...(snip)
Your ability for psychological projection is amazing, Michael.
You spend a few K's painstakingly putting together a very cunning
personal attack on myself, other MVP's, MCSD's, and Microsoft,
as detailed in this posting...and yet you feel insulted when those
attacks are rebutted.
You should stick to technical arguments.
As mentioned earlier, you're quite good at that.
re :
>"Arguing with people on newsgroups is like wrestling with a pig: the pig
>enjoys it and, after awhile, you both start to look the same."
I'll agree 100% with you on this one.
That wouldn't have been yet ANOTHER "ad hominem attack"
from you, Michael, would it ?
The only thing left to determine is : who's the pig ?
Our kind readers might be able to determine that.
Aaron Bertrand
> question asked by
> steve hall <sh...@uaex.edu> was
> > Is there a faster way to get a recordest than by calling a DLL?
> I have provided him with the correct answer: execute a stored procedure.
I disagree. I *WILL* say that in *some* cases (e.g. a batch stored
procedure that doesn't return any data), the "transaction time" will be
faster executed by a script call than by calling a component whose only
purpose is to call that stored procedure. However, any programmer worth his
weight in salt would not attempt to write a component that makes one simple
call. We all know that we are not calling a stored procedure to retrieve a
recordset and do nothing with it.
Components we've written, some in VB, some in C++, almost invariably call
stored procedures (some that return data, some that don't). And in 100% of
those scenarios, we've found that storing our business logic in components
has substantially upped the performance of the ASP pages that call them. No
exceptions... some were minimal performance gains (stopwatch material), most
were noticeable "wow, that page is responding much quicker" type of human
responses. I will again concede that none of these ASP pages looked like
this:
<%
set conn = createobject("adodb.connection")
conn.open "driver={SQL Server};server=..."
conn.execute("exec batch_stored_procedure")
conn.close: set conn = nothing
response.end
%>
We don't write applications like that. We write applications that DO
THINGS. And we've found (not read) that components speed up the execution
of the kinds of things we do. If you find ASP scripts faster at executing
single stored procedures, then by all means go ahead and use them. But
don't come out with a blanket statement that DLLs are slower than ASP
script. And don't mislead people into believing that ASP scripts can ever
be "compiled" or otherwise converted to P-code... cause it ain't gonna
happen.
> a) the compiler for VBScript is in VBScript.dll, the compiler for
> JScript in JScript.dll, etc.
I'm almost at LOL state here. These are NOT "compilers" - VBScript, nor
JScript, can be compiled. Code in either language can NOT be converted to
P-Code. You've taken Microsoft's keyword "precompiled" (which is about as
true to meaning as mission critical) and extrapolated what you think that
means for VBScript/JScript in the context of ASP (the exact same behavior
you're wrongly accusing Juan of).
> The phrase "precompiled" is very clear. It means "already compiled". It
> does not mean "something you do before you compile".
I disagree.
> To redo it each time would be an appalling waste
> of both resources and a programming misjudgement of the first order.
Which is why, for any significant amount of code, components run faster than
ASP files: the former are COMPILED, the latter are NOT.
> And, whereas the question as to whether ASP script is compiled once only
> or upon each execution is a sidetrack issue, it is one I willingly
> engage in. And here again I stand by my contention: ASP scripts are
> precompiled in the *full* sense of that word: I contend that the
> precompiled script includes a symbol table and ready-to-execute P-code.
No.
> When faced with a complex system, such as a web server, I do try to
> break the system into it's various pieces and examine each
> independently.
That's illogical. No one piece of a web server ever acts independently.
--
- a
Michael D. Kersey
> The only thing left to determine is : who's the pig?
I'll engage discussion with you in this thread no longer.
*plonk*
Aaron Bertrand
--
- a
Michael D. Kersey
>
> > Yes, but that is exactly where this thread originated: the original
> > question asked by
> > steve hall <sh...@uaex.edu> was
> > > Is there a faster way to get a recordest than by calling a DLL?
> > I have provided him with the correct answer: execute a stored procedure.
>
I never said that. I did say a number of things including:
a) That the overhead of using a component to do an operation is often so
great that the code will run more quickly as script,
b) that a stored procedure will fetch and return a result set faster
than a component that executes the same stored procedure (this is
trivially obvious, yet I'm still getting flack for it),
> And don't mislead people into believing that ASP scripts can ever
> be "compiled" or otherwise converted to P-code... cause it ain't gonna
> happen.
> > a) the compiler for VBScript is in VBScript.dll, the compiler for
> > JScript in JScript.dll, etc.
>
> I'm almost at LOL state here. These are NOT "compilers" - VBScript, nor
> JScript, can be compiled. Code in either language can NOT be converted to
> P-Code. You've taken Microsoft's keyword "precompiled" (which is about as
> true to meaning as mission critical) and extrapolated what you think that
> means for VBScript/JScript in the context of ASP (the exact same behavior
> you're wrongly accusing Juan of).
>
> > The phrase "precompiled" is very clear. It means "already compiled". It
> > does not mean "something you do before you compile".
>
> I disagree.
>
> > To redo it each time would be an appalling waste
> > of both resources and a programming misjudgement of the first order.
>
> Which is why, for any significant amount of code, components run faster than
> ASP files: the former are COMPILED, the latter are NOT.
That is not the only reason: VBScript has to do dynamic type-checking
and conversion, something that other languages need not perform. This
additional overhead would make VBScript slower than other languages
whether it is compiled or not.
Another contention(please bear with me):
On the first execution, an ASP script is lexically scanned, a syntax
tree created and pcode generated and the pcode and data are cached. On
subsequent executions, if the source file remains unchanged and the
cached information(pcode and data, etc.) is still available, then that
is loaded to memory and execution initiated without the burdensome
(lexical scan, syntax tree, pcode generation) sequence being repeated.
If this is not so, then indeed this is how it SHOULD be done! If I am
wrong, then a method has been found whereby Microsoft could speed ASP
script execution significantly. But I really don't think that
Microsoft's developers have overlooked this situation. I believe that
they have addressed it and that indeed my interpretation of events is
correct.
CALL FOR HELP TO KNOWLEDGEABLE MICROSOFT PERSONNEL
==================================================
Further, while I admire you, neither you nor I are appropriate
authorities to provide information on the internals of ASP.dll and
VBScript.dll in this particular matter. For that reason, I ask that
Microsoft provide a clear explanation of the sequence of execution of
script (both VBScript and JScript) in ASP, clear definitions of the term
"interpret", "precompile", "compile-time" and "runtime" with respect to
the ASP scripting framework and the significance of the various server
parameters including SCRIPTFILECACHESIZE, AspScriptFileCacheSize, and
SCRIPTFILECACHETTL.
In the meantime, you might want to examine VBScript.dll (my version is
4.0.0.2926) and Jscript.dll to search for the following strings. Using a
case-insensitive search I found these strings:
pcode
CompileScript
runtimeobjecttable
CompileScriptException
RuntimeScriptException
ScriptRuntime
NameTable
HashTable
and my favorites:
?GenerateCode@Parser@@AAEXPAUParseNode@@PAXJPBGJ2@Z
?GenPcodeEndSection@Parser@@AAEPAUBlob@1@PAJ@Z
?GenPcodeBegSection@Parser@@AAEXXZ
?GenPcodeEndSection@Parser@@AAEPAUBlob@1@PAJ@Z
For example, open a DOS prompt and do a
>FIND "pcode" VBSCRIPT.DLL|MORE
to find the references to "pcode". Similarly
Using FIND generates a page full of text, so it's easier if you use an
editor that will examine executables and dlls.
Now this proves nothing, but provides at least some support for my
contention that there is pcode generation in VBScript.dll.
> > When faced with a complex system, such as a web server, I do try to
> > break the system into it's various pieces and examine each
> > independently.
>
> That's illogical. No one piece of a web server ever acts independently.
My, my. So you just develop solutions to your complex problems whole,
all at once? I wonder what your documentation looks like. Although your
phrase is directly from Dr. Spock, the thought is not!-))
Juan T. Llibre [MVP]
First of all, to address the point of whether the script engines are compilers or not: yes and no.
(Just the kind of answer you expect to get from Microsoft, I suppose. :-) )
The script engines compile into a proprietary bytecode format.
There's a tool to debug the code generator that dumps the bytecodes out in human-readable format.
Consider this program:
Function Fib(n)
If n = 1 Or n = 2 Then
Fib = 1
Else
Fib = Fib(n-1) + Fib(n-2)
End If
End Function
window.alert Fib(5)
----- Here's the bytecode generated -----
Dump of EXEC at 00E563B0:
Function count = 1
Global code [max stack = 3]:
flags = (8000) noconnect
Pcode:
0000 OP_FnBind 'Fib' 1 PUBL
***BOS(135,154)*** window.alert Fib(5) *****
000A OP_Bos1 0
000C OP_NamedAdr 'window'
0011 OP_IntConst 5
0013 OP_CallNmdAdr 'Fib' 1
001A OP_CallMemVoid 'alert' 1
0021 OP_Bos0
0022 OP_FuncEnd
Function 1 ('Fib') [max stack = 3]:
flags = (8000) noconnect
arg count = 1
arg -1 = ref Variant 'n'
lcl count = 0
Pcode:
***BOS(21,43)*** If n = 1 Or n = 2 Then *****
0000 OP_Bos1 0
0002 OP_LocalAdr -1
0005 OP_IntConst 1
0007 OP_FixType
0008 OP_EQ
0009 OP_LocalAdr -1
000C OP_IntConst 2
000E OP_FixType
000F OP_EQ
0010 OP_BitOr
0011 OP_JccFalse 0023
***BOS(53,60)*** Fib = 1 *****
0016 OP_Bos1 1
0018 OP_IntConst 1
001A OP_LocalSt 0
001D OP_Bos0
001E OP_Jmp 0043
***BOS(80,105)*** Fib = Fib(n-1) + Fib(n-2) *****
0023 OP_Bos1 2
0025 OP_LocalAdr -1
0028 OP_IntConst 1
002A OP_Sub
002B OP_CallNmdAdr 'Fib' 1
0032 OP_LocalAdr -1
0035 OP_IntConst 2
0037 OP_Sub
0038 OP_CallNmdAdr 'Fib' 1
003F OP_Add
0040 OP_LocalSt 0
***BOS(119,131)*** End Function *****
0043 OP_Bos1 3
0045 OP_FnReturn
0046 OP_Bos0
0047 OP_FuncEnd
By examining this bytecode sequence you can easily figure out how it works.
There's a number of blocks that represent functions (and global code), and those consist of a series of statements.
Statements are separated by BeginningOfStatement ( BOS ) codes.
The virtual machine is a simple stack machine with no registers.
Here's how Active Server Pages works :
First of all, the server maintains a cache of threads and a cache of script engines.
Suppose a request comes in for this page, time.asp:
<html>
<% Response.write Now() %>
</html>
The first thing the server does is check to see if this page has been compiled already.
Suppose it hasn't. It then transforms the ASP source code into script source code.
Response.WriteBlock 0
Response.Write Now()
Response.WriteBlock 1
ASP then fetches a thread from the thread pool, an engine from the engine pool, and associates that engine with that thread.
It creates a Response object which has been initialized with the blocks "<html>" and "</html>"
so that WriteBlock writes the correct code out to the HTML stream.
It passes the Response object to the script engine, passes the code in, compiles it and runs it.
Once the run is complete, that engine goes back to the script engine pool and the thread goes back to the thread pool.
Now suppose another request for time.asp comes in.
This time, ASP realizes that there already IS an engine in the pool that has the compiled state!
So it grabs a thread, grabs the engine, adds the Response object to it again, and runs the code.
No need to compile the code the second time -- the script engine already has that state.
Now, suppose that time.asp is taking a while -- there might be a loop in there or something --
and another request comes in before the first one is done.
This time ASP realizes "I have the compiled state but the engine is already running on one thread".
So ASP calls a free-threaded function on the script engine "Clone",
which creates a new identical engine with the SAME compiled state as the first.
This is more expensive than allocating a new engine but it is cheaper than allocating a new engine AND re-compiling the code.
So now there are two threads and two engines running the same code, and when they're done, they both go back to the pool.
The caches are designed so that in typical scenarios the code only needs to be compiled once.
If the cache ever gets full, obviously state will be thrown away and will have to be re-compiled later.
All the details of the symbol tables, the compiled code blocks, etc, are managed by the script engine.
The ASP engine merely knows how to "reset" the engines (so that the engine believes that none of the code
has been run yet and hence needs to be re-executed) and how to make new engines cloned from old ones.
And of course how to turn .asp's into script code.
-----------
at least on the "compilation" part.
Though Michael wasn't 100% on target, he was closer to the truth than we were.
That doesn't let you off the hook, Michael, for all the unneeded "ad hominem" and "marketing ploy" stuff, though.
Juan T. Llibre
Director, Computer Sciences School
Universidad Nacional Pedro Henríquez Ureña
Microsoft Internet Development MVP [IIS/ASP]
ASP Resource : http://asptracker.com/
====================================
Alan Silver
<send_spam...@my-deja.com> writes
><%
>set conn = createobject("adodb.connection")
>conn.open "driver={SQL Server};server=..."
>conn.execute("exec batch_stored_procedure")
>conn.close: set conn = nothing
>response.end
>%>
>
>We don't write applications like that. We write applications that DO
>THINGS. And we've found (not read) that components speed up the execution
>of the kinds of things we do.
I don't want to get involved in the semi-war that seems to be going on
here, but you've got me intrigued. I admit to being fairly new (5-6
months with ASP, but years of programming), but I want to get in deep.
What sort of applications do you write ? So far most of mine have looked
like the example you showed above. I'm really interested to know what
you do that's so much more.
I'm not being rude and I'm certainly not disputing your claim, I'm just
very interested. I'd like to get into the "hard stuff" and want to know
what sorts of things are out there. I have found ASP pretty easy so far,
even database access is a doddle compared to other programming
languages/methods/etc I've tried. I want to know what the Big Boys are
doing !!!
thanx
--
Alan Silver
Please remove the "furryferret" if replying by e-mail
Adrian Forbes
more where you put it. The discussion (read flame war) is about what is
best; ADO access in ASP or calling a COM object to do the access. I was
told by the guys at Microsoft themselves that they didn't expect people
would put database access directly in their ASP code and said it wasn't the
way things were intended to be done.
So basically, if your code does something like
set conn = createobject("adodb.connection")
conn.open "driver={SQL Server};server=..."
conn.execute("exec batch_stored_procedure")
Then that code could be packaged in a COM object so that on the ASP you'd
have
set objMyObject = CreateObject("MyObject.MyClass")
objMyObject.DoBatch
This makes the ASP code easier to read and maintain. Also VB is a better
language to develop in than VBScript and you get more power and flexibility
from your code if the code is in a COM object.
Aaron Bertrand
> like the example you showed above. I'm really interested to know what
> you do that's so much more.
I can't show you stuff I do here at work, but here's a recent side project I
orchestrated. It's an application that was written using a DLL and stored
procedures. The actual ASP code for this entire schedule is about 5 lines
long, including invoking the a DLL and calling its methods. For example,
one of the pages looks like this:
<html>
<head>
<title>MerleFest 2000</title>
<!--#include file="css.asp"-->
<%
a = replace(Request("artist"),"'","''")
s = replace(Request("showname"),"'","''")
%>
</head>
<body bgcolor=#ffffff><center> <br>
<%
set grid = server.CreateObject("MerleFest.AaronSchedule")
grid.DrawSchedule a,s
set grid = nothing
%>
</body></html>
The result (HTML table schedules) was probably 5 times faster to return to
the browser when I first moved the code into DLLs. I enhanced the code
further to shorten the execution time (which I could have done in ASP as
well, I suppose, to get a more accurate "conversion rate").
The biggest PITA for this code was generating such a complex table... the
cells that represent stage times actually overlap. The individual artists
schedule was nothing, but the stage and date schedules are very different
beasts. I think you have to look at it to appreciate it... I could spew for
hours about how difficult it was, and how slow it was before I converted it
to a DLL. :-)
--
- a
Alan Silver
amless.ntli.net> writes
question. All you have explained is how and why you might put the code
for database access into a COM object rather than put it in the ASP.
I was asking what was meant by "code that really does things", as
opposed to the (apparently) simple routines that were quoted. As far as
I can see, your explanation tells me that the code itself isn't actually
doing anything more, it's just doing it in a slightly different and
(apparently) more efficient way. The end result (ie the black box that
the user sees) is no different.
Alan
Adrian Forbes
and write to that? I've heard that you can access objects like Response etc
from a COM object but never actually done it myself. Is that what's going
on?
Adrian Forbes
> opposed to the (apparently) simple routines that were quoted.
Then I assume you are asking for some examples from Aaron. Personally I
work a lot on ECommerce apps. From one method the component has to check a
database to make sure the card is valid and all info that is mandatory has
been given, use TCP/IP to contact third-party software and also the bank,
then audit the activity in a database. Yet this all gets done in one method
call, three lines of code.
Create Object
AuthoriseCard
destroy object
The "code that really does things" in that app is mainly TCP/IP
communications which can't be done from ASP anyway. Other examples I've
worked on are employee shecdule apps. Again, from one method the schedules
for the employee are checked against their curent hours to make sure the new
hours are legal, then stores all the info in the database, then has to check
things like adjoining hours, breaks periods...basically all sorts of stuff.
And as new rules come in the object itself is updated, the ASP code remains
the same....three lines. It would be possible to do this work right from
ASP but I'd hate to work on that page!
> The end result (ie the black box that the user sees) is no different.
It's not just the user that should have a black box, though. Personally I
work on the whole shebang, but having the code in COM objects lets others
use the functionality as a black box. Again when I use other's components I
also get the same black box effect. That way if you only know ASP then you
can easily use those components.
Aaron Bertrand
Yes.
--
- a
Aaron Bertrand
>
> My, my. So you just develop solutions to your complex problems whole,
> all at once?
Of course not, Mr. Facetious. What I mean is that you can't develop one
piece of your solution without having most, if not all, of the other pieces
in mind.
> I wonder what your documentation looks like.
I don't really care what you think of my documentation. I've never let a
client down.
--
- a
Alan Silver
<send_spam...@my-deja.com> writes
>> What sort of applications do you write ? So far most of mine have looked
>> like the example you showed above. I'm really interested to know what
>> you do that's so much more.
>
>I can't show you stuff I do here at work, but here's a recent side project I
>orchestrated. It's an application that was written using a DLL and stored
>procedures. The actual ASP code for this entire schedule is about 5 lines
>long, including invoking the a DLL and calling its methods. For example,
>one of the pages looks like this:
<Snip>
>The biggest PITA for this code was generating such a complex table... the
>cells that represent stage times actually overlap. The individual artists
>schedule was nothing, but the stage and date schedules are very different
>beasts. I think you have to look at it to appreciate it... I could spew for
>hours about how difficult it was, and how slow it was before I converted it
>to a DLL. :-)
>
>http://204.84.96.99/grid/
I'm impressed. I see what you mean about the overlapping cells.
Anyway, I get the impression that what you have done here is basically
nothing more than you could have done in ASP alone, but you have coded
it into DLLs for speed. Is this right ? I don't mean to imply it's not
impressive, I'm just trying to get a handle on what you've done.
Assuming I'm right, where would I find guidelines on when to write DLLs
and when to code in VBScript in an ASP. I can think of some quick and
simple database access stuff that I have done that would probably be
slower in a DLL as the time taken to create the object is probably
longer than the time taken to execute the query. I could be wrong, but I
suspect that writing a DLL for a simple job like that would be overkill.
Obviously for something as complex as your festival site there is a
great advantage to the DLL approach.
Also, any idea where I would find info on the best way to tackle this
sort of task ? Let's say I want to do something like your example
(ignoring the complexity of the table for the moment). I would have a
large SQL Server database containing all of the info, and I want to pull
out the relevant bits. At the moment I would do the standard "create
connection, open connection, save results into recordset and loop
through recordset to display" approach. How would I tackle the same
thing in a DLL ?
I realise I'm asking a lot, this is obviously a bit subject. I don't
expect you to provide step-by-step instructions (although that would be
nice ...), but pointers to web pages, books, etc would be helpful. I'm
keen to get into this stuff, but working at home means I'm a bit
isolated and need pointers as to where to find the info.
Thanx once again for your very helpful postings.
Adrian Forbes
While we're on the subject, fancy posting a snippet of code so I can see how
it's done?
Aaron Bertrand
> nothing more than you could have done in ASP alone, but you have coded
> it into DLLs for speed. Is this right ?
That was the main reason, yes. And my "theory" was proven as the app, while
it is still a little slow IMHO, is much faster than it was in plain ASP.
> Assuming I'm right, where would I find guidelines on when to write DLLs
> and when to code in VBScript in an ASP.
Because of the vast multitude of tasks ASP can perform, and because of the
infinite ways scripts are put together (and their varying
lengths/complexity), I don't think there are any hard and fast rules. I
haven't used DLLs for every single ASP project I've worked on, and I've
worked on some long ones. That decision wasn't always because of the speed
factors; DLLs are often foregone in my company because of the debugging
process and/or maintainability by lower-end programmers.
> I can think of some quick and
> simple database access stuff that I have done that would probably be
> slower in a DLL as the time taken to create the object is probably
> longer than the time taken to execute the query.
For very simple things, you're probably right. Anything more, and that
"hard hit" is only felt the first time the object is loaded into IIS'
memory. After that, you'd be hard-pressed to prove that the DLL really is
slowing you down. I've run many tests on this and it seems that the
"terrible overhead" that everyone keeps complaining about is only felt the
first time the DLL is loaded. But by all means, as you get into this you
should test it for yourself. Here are the tests I've run:
- batch stored procedure insert, no data returned
- batch stored procedure insert, data returned
- regular insert, no data returned
- regular insert, data returned
- stored procedure recordset retrieval
- regular recordset retrieval
The first four provided negligible timing differences, but the key here is
that the DLL's performance was NOT worse. So if any of the other advantages
to using a DLL appeal to you, then it doesn't HURT to use one. The latter
two provided reasonable improvements in speed, in the 10% range. I can go
back and dig up my test data if you want, I think it's backed up on our file
server somewhere.
> through recordset to display" approach. How would I tackle the same
> thing in a DLL ?
If the results are to be the same (a table of rows), then there would be no
difference.
Here is a pretty straight-forward article of creating an ActiveX DLL to
handle a simple SP insert to a SQL Server database... it is probably in the
"overkill for a DLL vein" but it should illustrate how little difference
there is in coding ASP vs. a DLL... if the end result warrants it.
http://msdn.microsoft.com/workshop/server/iis/404track.asp
--
- a
Aaron Bertrand
Services Type Library (Windows 2000) or MS Transaction Server Type Library
(previous)]. Then do this:
<snip>
Option Explicit
Public objContext As ObjectContext
Public objResponse As ASPTypeLibrary.Response
Public Function write() As Long
Set objContext = GetObjectContext()
Set objResponse = objContext("Response")
objResponse.Write "Hi, I come from the component."
End Function
</snip>
Then call your component as normal:
<%
set c = server.createobject("dll.adrianforbes")
c.write()
set c = nothing
%>
--
- a
Adrian Forbes
Aaron Bertrand
of my applications, but I use this kind of code all the time.
--
- a
"Adrian Forbes" <adrian...@spamless.ntli.net> wrote in message
news:uh1RdoZQ$GA.259@cppssbbsa04...
Adrian Forbes
Michael D. Kersey
<SNIPPED>
> here, but you've got me intrigued. I admit to being fairly new (5-6
> months with ASP, but years of programming), but I want to get in deep.
Welcome to the pigpen: You're already in up to your elbows!-))
> I want to know what the Big Boys are doing !!!
Do you want to know what they're doing or what they SHOULD be doing?
Is this a quote from a "big boy"?
> The best way to write a more efficient IIS Application
> is to throw as much code as you can into components.
> regards,
> Juan T. Llibre
> Director, Computer Sciences School
> Universidad Nacional Pedro Henríquez Ureña
> Microsoft Internet Development MVP [IIS/ASP]
> Co-Author : "Beginning Active Server Pages 2.0"
> ASP Resource : http://asptracker.com/
from an earlier post on this topic.
So perhaps, if you want to be a "big boy" you can follow his advice.
Now, since no one has offered support for my arguments on this topic and
yet my claims have indeed been proven correct, I will neither
pontificate nor unwittingly mislead as does Mr. Llibre. Instead I will
provide some information from yet another authority:
"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)
The book goes on to describe in more detail the circumstances under
which one should use components.
So it seems you have a choice:
a) defer to authority,
b) think, read, digest, compare, test, analyze and determine your own
conclusions (indeed, on this topic, "the road less travelled.").
Aaron Bertrand
And who determines what we "should" be doing, your drithel or what we've
tested and proven has worked better in our situation?
> "Rule of thumb: unless there are at least 100 lines of script and some
> big loops in that script,
That's a pretty scientific analysis, thanks.
> b) think, read, digest, compare, test, analyze and determine your own
> conclusions (indeed, on this topic, "the road less travelled.").
I believe that's what I suggested to do for whatever scenario was
appropriate.
"But by all means, as you get into this you should test it for yourself."
--
- a
Alan Silver
pamless.ntli.net> writes
>> I was asking what was meant by "code that really does things", as
>> opposed to the (apparently) simple routines that were quoted.
>
>Then I assume you are asking for some examples from Aaron.
Basically yes. Not too specific as I assume he, like most of us, is
working on something that he doesn't want making public until it's
ready. I'm really interested to know if he (and anyone else of course)
is really doing much more than me, or if they're doing the same thing in
more efficient ways (like coding DLLs).
> Personally I
>work a lot on ECommerce apps. From one method the component has to check a
>database to make sure the card is valid and all info that is mandatory has
>been given, use TCP/IP to contact third-party software and also the bank,
>then audit the activity in a database. Yet this all gets done in one method
>call, three lines of code.
>
>Create Object
>AuthoriseCard
>destroy object
>
>The "code that really does things" in that app is mainly TCP/IP
>communications which can't be done from ASP anyway. Other examples I've
>worked on are employee shecdule apps. Again, from one method the schedules
>for the employee are checked against their curent hours to make sure the new
>hours are legal, then stores all the info in the database, then has to check
>things like adjoining hours, breaks periods...basically all sorts of stuff.
>And as new rules come in the object itself is updated, the ASP code remains
>the same....three lines. It would be possible to do this work right from
>ASP but I'd hate to work on that page!
Right. I've just done a similar (ish) thing, but I passed the data to a
CGI script which is where the actual credit card transaction took place.
I can see the advantage in wrapping that up into an object.
>
>> The end result (ie the black box that the user sees) is no different.
>
>It's not just the user that should have a black box, though. Personally I
>work on the whole shebang, but having the code in COM objects lets others
>use the functionality as a black box. Again when I use other's components I
>also get the same black box effect. That way if you only know ASP then you
>can easily use those components.
Good point.
So I think my basic idea was right. We are really talking about doing
the same things as before, but applying a more efficient approach, both
in code-writing (ie your three lines of code instead of large wads) and
in execution speed.
Alan Silver
<send_spam...@my-deja.com> writes
>> Anyway, I get the impression that what you have done here is basically
>> nothing more than you could have done in ASP alone, but you have coded
>> it into DLLs for speed. Is this right ?
>
>That was the main reason, yes. And my "theory" was proven as the app, while
>it is still a little slow IMHO, is much faster than it was in plain ASP.
I didn't mean to imply that you were wrong. I am a mathematician by
training, and to me a theory is something you can prove. If you can't
prove it, then it's a hypotheses.
>> I can think of some quick and
>> simple database access stuff that I have done that would probably be
>> slower in a DLL as the time taken to create the object is probably
>> longer than the time taken to execute the query.
>
>For very simple things, you're probably right. Anything more, and that
>"hard hit" is only felt the first time the object is loaded into IIS'
>memory. After that, you'd be hard-pressed to prove that the DLL really is
>slowing you down. I've run many tests on this and it seems that the
>"terrible overhead" that everyone keeps complaining about is only felt the
>first time the DLL is loaded.
I'm only going on hearsay, I've never written a COM DLL yet, so I can
only repeat what I've heard. You give a compelling argument against a
lot of the folklore I've heard. What you say makes sense as one of the
big advantages of IIS over (say) most UNIX servers is the fact that they
load modules and keep them there, saving time next time round.
> But by all means, as you get into this you
>should test it for yourself.
I would like to, but at the moment I'm more interested in hearing the
opinion of people (like you) who know what they're talking about.
Without that I wouldn't know if I was even doing the right thing looking
at DLLs at all.
Once again thanx for all of your help. I would like to try this out as
it looks like a major way of going into "real" web programming.
Alan
Aaron Bertrand
I know, I didn't put the quotes around that for you specifically. :-)
> I would like to, but at the moment I'm more interested in hearing the
> opinion of people (like you) who know what they're talking about.
That in and of itself is obviously a matter of opinion. :-)
--
- a
Aaron Bertrand
> I AM THE GREATEST!!! THE PIG IS DOWN FOR THE COUNT!!!
> (dance)
If this is the way you celebrate every time you "win" an argument, adios.
You are definitely the pig in this barnyard.
> You won't accept them in the future.
I don't blame him.
> Fewer will be willing to engage in honest discussion with you on this
> and other newsgroups because of the shit that you've dragged me through.
LOL!
*PLONK*
Alan Silver
<send_spam...@my-deja.com> writes
>> I didn't mean to imply that you were wrong.
>
>I know, I didn't put the quotes around that for you specifically. :-)
Jolly good. I can go to bed happy now. Actually I always go to bed
happy. It's my favourite place.
>> I would like to, but at the moment I'm more interested in hearing the
>> opinion of people (like you) who know what they're talking about.
>
>That in and of itself is obviously a matter of opinion. :-)
True, but you certainly know more than me (no great compliment I know)
and you *sound* convincing !! Got any bridges you want to sell me ?
Alan Silver
<send_spam...@my-deja.com> writes
>Here is a pretty straight-forward article of creating an ActiveX DLL to
>handle a simple SP insert to a SQL Server database... it is probably in the
>"overkill for a DLL vein" but it should illustrate how little difference
>there is in coding ASP vs. a DLL... if the end result warrants it.
>
>http://msdn.microsoft.com/workshop/server/iis/404track.asp
Thanx for this. I've now had time to look at it properly. Two questions
come out of it ...
1) You got me interested, so I had a play with this. I decided to start
small, with a very basic DLL so I could see how things work. I tried
creating a VB DLL with the following world-shatteringly important code
...
Option Explicit
Public context As ObjectContext
Public req As ASPTypeLibrary.Request
Public Function listFerrets() As String
listFerrets = "Freddy, Frederick and Fredina"
End Function
Public Function getSV(ByVal s As String) As String
getSV = req.ServerVariables(s)
End Function
I then copied it to C:\winnt\system32 and registered it. I created the
following ASP ...
<%@ Language=VBScript %>
<%Option Explicit%>
<html>
<body>
<%
dim f
set f = server.createobject("AlanTest.Ferret")
%>
<p>ferrets = <%=f.listFerrets()%>
</p>
</body>
</html>
This worked fine, listing the names of my fave ferrets. But, when I
changed the code to ...
dim f,s
set f = server.createobject("AlanTest.Ferret")
s = f.getSV("SCRIPT_NAME")
I got the following error ..
AlanTest error '800a005b'
Object variable or With block variable not set
/ferret.asp, line 14
where line 14 is the new one (s = f.getSV(...))
What am I doing wrong ? Sorry to bore you with such a basic question,
but it's the first DLL I've written, and I reckon if I can crack the
simple stuff like this (ie how to get at server objects), then writing
the more complex stuff shouldn't be any more difficult than doing it in
ASP.
2) What is the development cycle for DLLs ? Your article had links to a
few others on the subject. I printed out loads and read them carefully,
but none described the process of modifying code, recompiling and
registering the new version. A few mentioned having to stop the server
and unregister the old version before registering the new one and
restarting the server, but no specific details.
Also, one of the articles, http://www.asptoday.com/articles/19990514.htm
mentioned a new feature in VB6 where you can test a recompiled DLL
without stopping the server. I couldn't find any more info on this.
Please could you either describe, or point me in the direction of a
description of a normal development cycle for DLLs. I got a bit confused
trying to work out how to change the code and have my ASPs see the new
DLL.
Thanx again for all of your help.
Randy Wilson
newsgroups and learned from them may I suggest the old saying - Never try to
teach a pig to dance - it just wastes your time and annoys the pig!
As a one-time (long ago) compiler writer for fun (boy that dates me, eh?) I
enjoyed the answer but am not sure it matters a bit to folks trying to use
most of the technology involved. Just my 2 cents. Later.
Randy Wilson
RWebs Consulting
"Aaron Bertrand" <send_spam...@my-deja.com> wrote in message
news:#03tuPbQ$GA.259@cppssbbsa04...
Juan T. Llibre [MVP]
Let's see :
1) We took opposing sides on an argument.
2) You couldn't prove your point.
3) I prove myself wrong...and prove you right.
4) You WHOPPEE and YIPPEE
5) You disparage me some more in a follow-up post ( quoted below )
quoting from 3 authors with whom I've co-authored books
Let's examine your latest barrage.
You quote me :
> > The best way to write a more efficient IIS Application
> > is to throw as much code as you can into components.
And say :
> Is this a quote from a "big boy"?
> So perhaps, if you want to be a "big boy" you can follow his advice.
> Now, since no one has offered support for my arguments on this topic and
> yet my claims have indeed been proven correct,
( Conveniently forgetting to mention that it was ME who proved you right. )
( Hmmm... I wonder if I "unwittingly misled" you.)
>I will neither
> pontificate nor unwittingly mislead as does Mr. Llibre. Instead I will
> provide some information from yet another authority:
and proceed to quote from my 3 co-authors regarding something
which I have NOT opposed, but which you are accomodatingly
interpreting that I have opposed.
When I say :
"throw as much code AS YOU CAN into components",
and my co-authors say :
>"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."
those are NOT opposing points of view.
To any, even casual, reader, the qualifier "AS MUCH CODE AS YOU CAN"
certainly would be intended to have SOME limits.
I have NOT advocated putting EVERYTHING in components,
so I could not, hardly, be "unwittingly misleading" no one.
I fail to see your technical point, but I do see a vicious intention on your
part
to do anything you can to, somehow, discredit me...when all you really
have accomplished is showing a very vicious attitude.
As far as I can see :
1) I was quite decent in providing you with correct info,
even though that meant reversing a previous point of mine.
2) You are very childish in a very mean sort of manner.
3) You have no respect for people who help you get facts.
4) You have a very vicious personality which doesn't deserve any assistance.
You're on your own from now on...
Juan T. Llibre
Director, Computer Sciences School
Universidad Nacional Pedro Henríquez Ureña
Microsoft Internet Development MVP [IIS/ASP]
Co-Author : "Beginning Active Server Pages 2.0"
ASP Resource : http://asptracker.com/
====================================
Michael D. Kersey <mdke...@hal-pc.org> wrote ...
> Alan Silver wrote:
> <SNIPPED>
> > I don't want to get involved in the semi-war that seems to be going on
> > here, but you've got me intrigued. I admit to being fairly new (5-6
> > months with ASP, but years of programming), but I want to get in deep.
>
> Welcome to the pigpen: You're already in up to your elbows!-))
>
> > I want to know what the Big Boys are doing !!!
>
> Do you want to know what they're doing or what they SHOULD be doing?
>
> Is this a quote from a "big boy"?
> > The best way to write a more efficient IIS Application
> > is to throw as much code as you can into components.
> > regards,
> > Juan T. Llibre
> > Director, Computer Sciences School
> > Universidad Nacional Pedro Henríquez Ureña
> > Microsoft Internet Development MVP [IIS/ASP]
> > Co-Author : "Beginning Active Server Pages 2.0"
> > ASP Resource : http://asptracker.com/
> from an earlier post on this topic.
> So perhaps, if you want to be a "big boy" you can follow his advice.
>
> Now, since no one has offered support for my arguments on this topic and
> yet my claims have indeed been proven correct, I will neither
> pontificate nor unwittingly mislead as does Mr. Llibre. Instead I will
> provide some information from yet another authority:
>
> "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)
>
> The book goes on to describe in more detail the circumstances under
> which one should use components.
>
> So it seems you have a choice:
> a) defer to authority,
Aaron Bertrand
your
> part
> to do anything you can to, somehow, discredit me...when all you really
> have accomplished is showing a very vicious attitude.
That's all I really see here, and I hope I'm not alone.
--
- a
Michael D. Kersey
> Aaron - as one who has read many answers you have provided in this and other
> newsgroups and learned from them may I suggest the old saying - Never try to
> teach a pig to dance - it just wastes your time and annoys the pig!
> As a one-time (long ago) compiler writer for fun (boy that dates me, eh?) I
> enjoyed the answer but am not sure it matters a bit to folks trying to use
> most of the technology involved. Just my 2 cents. Later.
> Randy Wilson
> RWebs Consulting
You needn't worry about Aaron - he's probably just irritated that he
stepped into the pigpen and slipped in the shit just before the pig went
down. That is, no sooner did Aaron announce that "Code in either
language can NOT be converted to P-Code." than Juan posted his findings
that pcodes are generated for both languages!
There at at least several reason why the answer matters:
I. Understanding how ASP works internally helps us understand how
certain web server parameters affect performance, and
II. As far as this topic's original title is concerned: it explains why
one must have a significantly large and/or complex script before it is
worthwhile to convert it to a COM component. Now it is clear that
scripts are compiled to pcodes and the pcodes interpreted, in a manner
similar to Visual Basic (which can optionally generate either pcodes or
native code). For this reason, it is difficult for another
similarly-compiled language to significantly outrun scripts until the
script complexity reaches a certain level. That level is defined by the
differences in compilation and consequent runtime execution(e.g., typed
vs. typeless language, effectiveness of compiler optimization) and by
the overhead of component creation/deletion/argument marshalling.
Aaron Bertrand
You're missing important parts:
Option Explicit
Public context As ObjectContext
Public req As ASPTypeLibrary.Request
Public Function listFerrets() As String
listFerrets = "Freddy, Frederick and Fredina"
End Function
Public Function getSV(ByVal s As String) As String
' BELOW HERE *********
Set objContext = GetObjectContext()
Set objRequest = objContext("Request")
' ABOVE HERE *********
getSV = req.ServerVariables(s)
End Function
That's what this error is:
> Object variable or With block variable not set
You've DECLARED the request object, but you haven't actually instantiated
(set) it.
> 2) What is the development cycle for DLLs ?
Like the reasons for or against using DLLs, this really depends on what the
DLL is intending to do, what kind of development cycle it would be if it
WEREN'T using a DLL, how many people are involved, the deadline, etc. etc.
In other words, it is much more dependent on the goal and other
circumstances of the project than on whether or not you're using a DLL
specifically.
Here's how I typically handle it:
(1) Storyboard the application (this is fairly typical/trivial and usually
goes on for a day to a week, depending on how many programmers are in the
circle, and how many of them have opposing viewpoints to your coding
techniques). :-)
(2) Prototype with ASP.
(3) Convert database queries to stored procedures.
(4) Convert ASP code to VB.
Sometimes (4) is never reached, again depending on many variables that we've
already discussed. And when it is, until the DLL is ready for deployment,
it is not tested on production machines, only development boxes. In which
case, restarting the web server is (for most people, anyway) a non-event.
This does not mean restarting the entire machine, only the IIS Service and
the web publishing service (+ SMTP/FTP if they're running). In my article
there is a nifty little batch file that makes really short work of this; I
run that batch file at least 10 times every day.
> modifying code, recompiling and registering the new version.
Only the first two steps are necessary, as long as development and testing
are occuring on the same machine; once the DLL is registered, IIS knows
where to find it if it isn't in memory (which is the case after you shut
down IIS and then restart it, which is also the only time you can re-compile
a DLL you've already accessed through the web server). And it also knows to
get the new version once you've compiled over the old one. This is why
testing on a development machine is so advantageous over developing on a
development machine and testing on a deployment machine: re-writes and mods
are so simple to take effect. Here is what I do:
(1) Test the ASP page... realize I made a mistake in my code, so I restart
IIS using the .bat file.
(2) Go into VB, mod the code, and re-compile (file, make filename.dll). [a]
(3) Test the ASP page again.
[a] [The only way you'll get an error here is if the ASP page that calls the
DLL was accessed on your server between the time the IIS service restarted
and the time you executed the re-compile command.]
> Also, one of the articles, http://www.asptoday.com/articles/19990514.htm
> mentioned a new feature in VB6 where you can test a recompiled DLL
> without stopping the server. I couldn't find any more info on this.
I haven't tried this. My restart.bat file is so second nature, combined
with the fact that I have no REASON to want to test my "DLLs in development"
on a machine where restarting IIS is taboo. If the machine is that
important, I shouldn't be developing on it. While one of the paragraphs
there was intriguing, and I may try it out, I'm vehemenently opposed to any
sort of debugging in VB or InterDev, so if it must make use of that
'feature', I'll likely pass on it. The kind of problems I typically
experience in ASP or VB code are caught faster by a browser than thay ever
would be by a debugger...
--
- a
Aaron Bertrand
> most of the technology involved.
Sure, I learned something here (though I *STILL* contend that, in my tests,
DLLs almost ALWAYS outperform similar ASP code, particularly when DB access
is concerned).
If Michael had kept the argument technical, as opposed to the type of
comments you'd hear at kindergarten recess, I might be a little more
tolerant. Well, another twit for the twit-file...
Thanks for the comments Randy,
--
- a
Michael D. Kersey
You didn't *prove* me right at all. My claims were correct to begin
with.
What you found, by consulting with Microsoft personnel, is that you
misunderstood how ASP works.
You may have paid for the consultation: if so, I believe that is OK.
Now it takes *considerable* intellectual integrity to admit you are
wrong, and that is an admirable trait. Especially when the level of
argument becomes intense. But, as they say, "If you can't take the heat,
stay out of the kitchen."
But you're going too far to claim that you did anything other than act
as an agent in providing information.
Had you done nothing, I would still be correct.
Computer science, and science in general, does not depend on
personalities or "feely-touchy" arguments: it's out there in the real
world. Many, if not most, of the most highly skilled people would appear
incredibly vicious to outsiders. In fact, my experience is that the
academic community is one of the most vicious in this regard.
Nonetheless the directness and aggressiveness of the individuals heats
the argument and tempers the results, like fine steel.
Nonetheless I do thank you for providing me with the public opportunity
to proclaim my correctness and to vent my frustration, whether I be an
ass about it or not.
And why the reference to your co-authors? What relevance is that to this
thread? Does it make a difference who you associate with? My quote was
from "Active Server Pages 3.0"(Wrox Ltd.,1999). I don't see your name
listed anywhere in the book.
Juan T. Llibre [MVP]
Michael D. Kersey <mdke...@hal-pc.org> wrote ...
re :
> You didn't *prove* me right at all. My claims were correct to begin
> with.
As I recall, a postulate is a postulate...not an axiom...until proven.
You postulated without proof.
I provided the proof, whether I originated it or not.
You obviously don't appreciate that,
but you aren't a very appreciative guy anyway.
re :
> But you're going too far to claim that you did anything other than act
> as an agent in providing information.
I did not claim anything other than that.
I credited the source, as I always do when quoting someone else.
re :
>whether I be an ass about it or not.
You were.
re :
> And why the reference to your co-authors? What relevance is that to this
> thread? Does it make a difference who you associate with? My quote was
> from "Active Server Pages 3.0"(Wrox Ltd.,1999). I don't see your name
> listed anywhere in the book.
Nevertheless, all 3 of them have been my co-authors on OTHER books.
You purposely quoted them to incorrectly state that I opposed their point of
view.
You are wrong in fact...and wrong to try to draw that inference just to
demean me,
which was your obvious intention.
It's such a shame that you prefer to waste your time, and others' time, on
vituperation.
Maybe someday you'll learn to be a bit humbler...and less abusive.
I'm not into abuse, ergo : adios, Michael.
May you learn and prosper.
Juan T. Llibre [MVP]
Not only that, Aaron, but there's also many more
considerations than just speed when developing ASP Applications.
For example, we may not want an ASP developer to be able
to directly access the databases in an Application we provided,
in such a way as to contradict the business rules the
Application must have.
For example, again, we may have a business rule that reads :
"when a customer is billed, a row must be inserted into
the 'AccountsPayable' table and then the 'Inventory' column
in the appropiate 'Products' table must be decremented."
If we allow the ASP developer scripted access to the database,
he may edit the script and only perform half of the tasks required
by the business rules.
But, if we provide the developer with a component method called
"BillCustomer",
we can make sure that all the business rules are followed accurately.
Speed is only half the programming story.
Making sure the ASP Application's business rules
are followed to the letter is just as important.
regards,
Juan T. Llibre
Director, Computer Sciences School
Universidad Nacional Pedro Henríquez Ureña
Microsoft Internet Development MVP [IIS/ASP]
Co-Author : "Beginning Active Server Pages 2.0"
ASP Resource : http://asptracker.com/
====================================
Aaron Bertrand wrote ...
> I disagree. I *WILL* say that in *some* cases (e.g. a batch stored
> procedure that doesn't return any data), the "transaction time" will be
> faster executed by a script call than by calling a component whose only
> purpose is to call that stored procedure. However, any programmer worth
his
> weight in salt would not attempt to write a component that makes one
simple
> call. We all know that we are not calling a stored procedure to retrieve
a
> recordset and do nothing with it.
>
> Components we've written, some in VB, some in C++, almost invariably call
> stored procedures (some that return data, some that don't). And in 100%
of
> those scenarios, we've found that storing our business logic in components
> has substantially upped the performance of the ASP pages that call them.
No
> exceptions... some were minimal performance gains (stopwatch material),
most
> were noticeable "wow, that page is responding much quicker" type of human
> responses.
> We write applications that DO THINGS.
> And we've found (not read) that components speed up
> the execution of the kinds of things we do.
Alan Silver
<send_spam...@my-deja.com> writes
>Well, another twit for the twit-file
I wonder if I'm in it ? Nah, I'm not clever enough.
Alan Silver
<send_spam...@my-deja.com> writes
>
>You're missing important parts:
Thanx for the help. I'll go and play with it a bit.
>> 2) What is the development cycle for DLLs ?
>
>Like the reasons for or against using DLLs, this really depends on what the
>DLL is intending to do, what kind of development cycle it would be if it
>WEREN'T using a DLL, how many people are involved, the deadline, etc. etc.
>In other words, it is much more dependent on the goal and other
>circumstances of the project than on whether or not you're using a DLL
>specifically.
<Comments snipped - only for space>
My situation is much simpler than yours. I sit alone at a stand-alone
machine and develop the web sites. No-one else uses this machine. When
the site is ready (or at an intermediate but acceptable stage) I upload
to the production server. I can do what I like to this machine and it
won't affect anybody or anything except myself.
For that purpose, most of the cycle you mentioned is unnecessary. I
guess, from your comments below, that I could do ...
1) Write the DLL and register it
2) write an ASP that uses the DLL and test it
3) restart IIS
4) go back to VB and modify the DLL. Recompile.
5) reload the ASP and see what mistakes I made this time
6) go back to 3 and loop until cooked
Any comments ?
I was mainly asking about the mechanics of how and when to recompile
against when to restart IIS. You basically answered that. Thanx.
>> modifying code, recompiling and registering the new version.
>
>Only the first two steps are necessary, as long as development and testing
>are occuring on the same machine; once the DLL is registered, IIS knows
>where to find it if it isn't in memory (which is the case after you shut
>down IIS and then restart it, which is also the only time you can re-compile
>a DLL you've already accessed through the web server). And it also knows to
>get the new version once you've compiled over the old one. This is why
>testing on a development machine is so advantageous over developing on a
>development machine and testing on a deployment machine: re-writes and mods
>are so simple to take effect.
As commented above, all of my writing and testing is on a development
machine. My code never touches the production server until I'm convinced
it's 100% working.
> Here is what I do:
>
>(1) Test the ASP page... realize I made a mistake in my code, so I restart
>IIS using the .bat file.
>(2) Go into VB, mod the code, and re-compile (file, make filename.dll). [a]
>(3) Test the ASP page again.
Sounds like what I described above. Good.
One small question. Do you set the compilation folder for the DLL to
something like C:\winnt\system32 so that the latest version is always
there, or do you compile to another directory and copy the DLL ? Does it
make any difference ?
>[a] [The only way you'll get an error here is if the ASP page that calls the
>DLL was accessed on your server between the time the IIS service restarted
>and the time you executed the re-compile command.]
Not going to happen unless someone can figure out how to hack into a
stand-alone machine when it's not dialled up to the Internet !!
>
>> Also, one of the articles, http://www.asptoday.com/articles/19990514.htm
>> mentioned a new feature in VB6 where you can test a recompiled DLL
>> without stopping the server. I couldn't find any more info on this.
>
>I haven't tried this. My restart.bat file is so second nature, combined
>with the fact that I have no REASON to want to test my "DLLs in development"
>on a machine where restarting IIS is taboo. If the machine is that
>important, I shouldn't be developing on it.
Hang on, we were talking about a machine where restarting IIS is not
taboo. Remember, we were both talking about a development machine.
I was just interested in how the feature works. Restarting IIS isn't so
terrible, it just wastes a minute or so when you're itching to get back
into the code and fix the mistakes (sorry, inadvertent design features).
> While one of the paragraphs
>there was intriguing, and I may try it out, I'm vehemenently opposed to any
>sort of debugging in VB or InterDev, so if it must make use of that
>'feature', I'll likely pass on it. The kind of problems I typically
>experience in ASP or VB code are caught faster by a browser than thay ever
>would be by a debugger...
I agree about debugging by VB or VI. I tend to run things (web pages,
java applets, programs, etc) as they will really be run and use things
like response.write to flag errors. I wasn't asking the question with
respect to debugging, more to do with speed of development. If you can
modify a DLL and then see how it works with a single mouse click or key
press, it's a whole lot faster than minimising VB to find your shortcut,
restarting IIS, recompiling the DLL and then reloading the page. I'm
just looking for fast development. In these days of sophisticated
software, I think we should be able to work as fast as our brains allow.
Slowing down due to menial tasks shouldn't be necessary.
Just my thoughts. Thanx again for all of your help.
Aaron Bertrand
My twit-file is a filter which prevent me having to view messages from
people who, for one reason or another, don't have anything to say that
interests me. If you were in it, I wouldn't be responding to your posts.
And no, I will not make my twit-file public. :-)
--
- a
chris...@my-deja.com
What can I do to tweek performance of a VB component ?
I just completed a benchmark of a VB component that did 2 counts & 2
selects on 2 100 row SQL tables. I was not creating a cusored recordset
but a recordset from the connection: rs = conn.execute(sql). I also
included the MTS object context in the VB code. I am also keeping state
to keep the DB connection open method calls to run the 4 queries. I
registered it in MTS as a component within a server package running
under my own userid (I am getting a lsaRegisterLoginProcess security
message the first time in the event viewer) . I deployed versions
with/without stored procedures. I also set it up as apartment threaded
that turned into free threaded when I installed it in MTS.
I used WAS stress tool to simulate 40 users over 10 connections. Why is
the component running slower (150ms vs 7000ms) & using more server
memory (44% vs 90%) than a ASP/ADO script ?. In the browser, they both
seem to run in under 2 seconds once the object is loaded the first
time. Do you need more code in the component to see the performance
leap ?
Any help would be appreciated
In article <OszpAngQ$GA.258@cppssbbsa04>,
Sent via Deja.com http://www.deja.com/
Before you buy.
Michael D. Kersey
Since I'm entered into Aaron's twit file, I can post whatever I want:
Aaron won't see any of it. You and I can. For Aaron, "Ignorance is
Bliss". Read on...
> If Michael had kept the argument technical, as opposed to the type of
> comments you'd hear at kindergarten recess, I might be a little more
> tolerant. Well, another twit for the twit-file...
This is nothing new and no loss to me. Aaron has *never* been tolerant
of me, even when I was on my best behavior. I'm too bright; he doesn't
understand me. To me he's a rather dull, plodding, rigid person. But in
his plodding he has covered a lot of ground. He is good at answering
questions in this group. In return,he gets much pleasure from people
stroking him. Unfortunately, if anyone on the newsgroup appears to be
competent, Aaron feels threatened. Juan does not threaten Aaron. Juan
and Aaron are buds: kinda like Pigman and Pigboy.
Aaron was once an MVP, but he's getting smarter slowly: he's not posting
with the MVP after his name. Juan is a Microsoft MVP.
MVPs get certain privileges from Microsoft (maybe a T-shirt here and
there, early releases of beta software, etc.). That topic has been
covered in past posts to this newsgroup.
MVPs provide Microsoft with valuable services at a laughingly low cost.
They server as an eager pool of software testers, again for free. "Hit
me! Beat me! Give me Beta software! Ahhhhhhh!!!!"
The roughly 7000 millionaires (!) that work or worked at Microsoft must
shake their heads and laugh in disbelief each time they think about the
MVPs who are out their busting their asses answering questions, working
for practically nothing: "Another latte', please."
And, here's the good part: the MVPs love it!
BTW does anybody know how many MVPs are millionaires?
See
http://www.seattletimes.com/extra/browse/html97/mony_071397.html
which discusses, among other things, "How many Microsoft millionaires
are there?"
Adrian Forbes
If I wanted to see flame wars and people dissin' each other I'd go to a
hacker forum. At the end of the day sometimes people have their different
views on "what is best" when it comes to technical matters. If you
genuinely believe you're right then post the info that backs that up. There
is no need to resort to petty name-calling and flaming.
Just my £0.02
Alan Silver
<send_spam...@my-deja.com> writes
I was only joking. I'm not *that* much of a twit !!
Alan Silver
<send_spam...@my-deja.com> writes
>
>You're missing important parts:
>
>
> Public context As ObjectContext
> Public req As ASPTypeLibrary.Request
>
> Public Function listFerrets() As String
> listFerrets = "Freddy, Frederick and Fredina"
> End Function
>
> Public Function getSV(ByVal s As String) As String
>' BELOW HERE *********
>
> Set objContext = GetObjectContext()
> Set objRequest = objContext("Request")
>
>' ABOVE HERE *********
>
> getSV = req.ServerVariables(s)
> End Function
Thanx very much. That seems better.
One problem I seem to be having is that when I try to restart IIS, it
hangs on me. I get the message ...
"The IIS Admin service hung on startup"
or something like that. Any idea ? I never had a problem with this
before, so I guess it's something to do with the DLL I wrote. This
didn't do much more than the bits you saw, so I'm not sure how I could
have done anything to IIS.
Thanx for any help
Michael D. Kersey
>
> All I can say is that banter like this is pretty sad in a technical forum.
> If I wanted to see flame wars and people dissin' each other I'd go to a
> hacker forum. At the end of the day sometimes people have their different
> views on "what is best" when it comes to technical matters. If you
> genuinely believe you're right then post the info that backs that up.
Fact is, Adrian, I not only posted the information, in the case of the
primary issue
I. "the best and fastest way to get a recordset."
I even posted it in the form of proofs.
Juan and Aaron persisted in incorrectly attacking me and my viewpoints.
Meanwhile a secondary (albeit significant) side-issue became apparent:
II. "what does it mean to say that VBScripts are 'precompiled'"?
On these technical issues I was dead on point and they were completely
wrong. Review the topic's various threads for details.
> There is no need to resort to petty name-calling and flaming.
You're right about this: we've gone too far. I'm sorry I introduced the
term "ad hominem" to Juan: he's added it to his vocabulary and is now
using it to label everything, like a new toy. But I have plenty of other
weapons in my backpack.
This *is* a technical newsgroup. I'm not like Rodney King: "Can't we all
just get along?" People must remember that, when they walk with me,
there's no quitting. I'll go through both your Hell and mine to get at
the truth. And if you fall at my side, I'll drag your weary ass through
the mud, flames and shit to get there.
>
> Just my £0.02
Aaron Bertrand
No matter where you go, there's always going to be one or two brats who
don't know how to grow up. As far as I'm concerned, more than enough time
has been wasted on this thread.
--
- ab
once, and still, mvp
Aaron Bertrand
> before, so I guess it's something to do with the DLL I wrote.
I haven't seen that happen, but I doubt the DLL caused it. What exactly
made your DLL different from the code I posted? How did you register it?
Did you add any references I didn't mention? Did you make other changes to
the Project? Did you use the batch file I described in the article? Did
you ever try restarting the web server in this way BEFORE this DLL was
registered? Does thie same error come up if you reboot the machine or log
in as a different user? Did you examine the event viewer for clues? Did
you look up the EXACT error message (not "or something like") in MSDN or the
KB?
--
ab/mvp
Michael D. Kersey
>
> Hi,
> What can I do to tweek performance of a VB component ?
> I just completed a benchmark of a VB component that did 2 counts & 2
> selects on 2 100 row SQL tables. I was not creating a cusored recordset
> but a recordset from the connection: rs = conn.execute(sql). I also
> included the MTS object context in the VB code. I am also keeping state
> to keep the DB connection open method calls to run the 4 queries. I
> registered it in MTS as a component within a server package running
> under my own userid (I am getting a lsaRegisterLoginProcess security
> message the first time in the event viewer) . I deployed versions
> with/without stored procedures. I also set it up as apartment threaded
> that turned into free threaded when I installed it in MTS.
> I used WAS stress tool to simulate 40 users over 10 connections. Why is
> the component running slower (150ms vs 7000ms) & using more server
> memory (44% vs 90%) than a ASP/ADO script ?. In the browser, they both
> seem to run in under 2 seconds once the object is loaded the first
> time. Do you need more code in the component to see the performance
> leap ?
>
> Any help would be appreciated
If all your component does is execute SQL queries, then script will
outrun a component that executes the same SQL queries. Reason is,
component (creation/deletion/marshalling of recordsets) overhead is
significant and gives no performance boost. The boost in a component
comes only if the procedure is sufficiently compute-bound so that the
component can catch up and then outrun script. Here's a timeline:
Case 1: Script calls SQL procedure:
===================================
Script >------------------| |----->
SQL procedure |----------|
Case 2: Script calls component that executes SQL procedure:
===========================================================
Script >------------------| |----->
Create component |-----| |
SQL procedure |----------|
As you can see, in this case the simple script runs faster. As soon as
the second script begins to create a component, it starts to fall
behind.
So 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)
John L.
--
John L.
"Adrian Forbes" <adrian...@spamless.ntli.net> wrote in message
news:O4p3lumQ$GA.277@cppssbbsa05...
> All I can say is that banter like this is pretty sad in a technical forum.
> If I wanted to see flame wars and people dissin' each other I'd go to a
> hacker forum. At the end of the day sometimes people have their different
> views on "what is best" when it comes to technical matters. If you
> genuinely believe you're right then post the info that backs that up.
There
> is no need to resort to petty name-calling and flaming.
>
> Just my £0.02
>
>
Alan Silver
<send_spam...@my-deja.com> writes
OK, to answer your questions in order.
1) The code I had was cut and pasted from your posting (with the
comments removed once I had worked out what you meant), so is just as
you saw. Having said that, I wrote another DLL to pull some info from a
database and I had the same problem. Here is the code for that ...
Public Function peek() As String
' shows the contents of the classifieds database as an unordered list
Dim conn As ADODB.Connection
Dim rs As ADODB.Recordset
Dim sql As String
Dim res As String
res = ""
Set conn = CreateObject("ADODB.Connection")
Set rs = CreateObject("ADODB.recordset")
sql = "select text from classified"
conn.Open "dsn=zoomquest;uid=sa;pwd=;"
rs.Open sql, conn, 3, 3
If Not rs.EOF Then
rs.MoveFirst
res = "<p><ul>" & vbCrLf
Do While Not rs.EOF
res = res & "<li>" & rs.Fields("text") & vbCrLf
rs.MoveNext
Loop
res = res & "</ul></p>" & vbCrLf
rs.Close
conn.Close
Else
res = "<p>No records found.</p>" & vbCrLf
End If
peek = res
End Function
This is pretty basic stuff. I have a table called "classified" with a
field called "text" in it. I just show all of the fields in an unordered
list. This works fine from the following ASP ...
dim d
set d = server.createobject("DBTest.DBPeek")
response.write(d.peek())
2) I registered it using regsvr32.exe (didn't find out until after that
VB registers components for you when you compile them). I tried
unregistering (several times in a row, just to make sure) to ensure that
I had removed all entries in the registry and then recompiling.
One odd thing : Whenever I have registered (third party) DLLs before,
and have wanted to unregister them (say before registering an updated
version), I have just done ...
regsvr32.exe /unregister ferret.dll
several times. I was told that if (by mistake) you register a DLL more
than once, multiple registry entries are created. Unregistering several
times should cure it.
But, with my two DLLs, I have unregistered them, but now get the
following error if I try to unregister again ...
LoadLibrary("alantest.dll") failed. GetLastError returns 0x0000007e
3) Project references are ...
Visual Vasic for Applications
Visual Basic runtime objects and procedures
Visual Basic objects and procedures
OEL automation
M/s ActiveX Data Objects 2.1 library *
M/s ActiveX Data Objects recordset 2.1 library
M/s Active server pages object library *
M/s active server pages 2.0 objectcontext class type library
Of these, I only added the ones with the *. The rest were added for me
(by VB itself I presume).
4) My batch file for restarting IIS looks like ...
net stop iisadmin /y
net start w3svc
which is what you use I believe. I don't have the SMTP, NNTP or FTP
services running automatically (I don't use them), so this only affects
the world wide web publishing service and the IIS admin service.
5) yes I have restarted the server many times before this and never had
a problem. As of last night, I could reboot the machine and restart IIS
without problem. I only had a problem when I loaded a page that uses the
DLL that I run into problems. For some reason I can't even do that now.
When I reboot the machine, IIS starts as normal. If I try restarting it
(without looking at any ASPs), the IIS admin service hangs.
6) The event viewer shows the message "The IIS Admin Service hung on
starting." with event ID 7022.
7) No I didn't look in MSDN yet. Apart from the fact that this was
bedtime last night, I assumed this was probably a stupid newbie's
mistake, for which I don't find MSDN very helpful.
Thanx for the reply.