| Author |
 Topic  |
|
mppeters
Starting Member
Canada
4 Posts |
 Posted - 29 April 2003 : 10:51:25
|
I thought it might be helpful to post some possible things to consider for the next version to further improve the speed of a great application.
1. Use Option Explicit
2. Use global.asa for ADO constants instead of inc_adovbs.asp.
<SCRIPT LANGUAGE=VBScript RUNAT=Server>
<!-- METADATA NAME="Microsoft ActiveX Data Objects 2.5 Library"
TYPE="TypeLib" UUID="{00000205-0000-0010-8000-00AA006D2EA4}" -->
</SCRIPT>
I don't think I'm saying anything profound here. Have these suggestions been considered before and excluded for a specific reason? |
Mark Petersen |
|
|
davemaxwell
Access 2000 Support Moderator
USA
3020 Posts |
Posted - 29 April 2003 : 11:04:45
|
Option Explicit: This is not used because it actually slows your system down in production. It's a great idea to use it in development because it forces you to declare your variables, which is where your slowdown is actually occurring. Once you've got all your variables declared, having option explicit declared since it has to verify all variables which you know already exist.
Global.asa: Not all sites allow you to use global.asa, which is why it's not allowed. Not sure how using the global.asa for constants would speed it up anymore than using the include. Can you elaborate on that portion of it? |
Dave Maxwell
Barbershop Harmony Freak |
 |
|
|
mppeters
Starting Member
Canada
4 Posts |
Posted - 29 April 2003 : 11:52:15
|
Option Explicit:
Taken from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnasp/html/asptips.asp
quote:
Tip 10: Use Option Explicit
Use Option Explicit in your .asp files. This directive placed at the top of the .asp file forces the developer to declare all variables that will be used. Many programmers consider this helpful in debugging applications, as it avoids the chance of mistyping a variable name and inadvertently creating new variables (for example, MyXLMString=... instead of MyXMLString=).
Perhaps more important, it turns out that declared variables are faster than undeclared variables. Under the covers, the scripting run time references undeclared variables by name, every time they are used. Declared variables, on the other hand, are assigned an ordinal, either at compile time or run time. Subsequently, declared variables are referenced by this ordinal. Since Option Explicit forces variable declaration, it insures that all variables are declared and thus will be accessed quickly.
My own experience is that Option Explicit does, in fact, speed up the application substantially. There have been several benchmarking studies done on the effect of Option Explicit and they all come to the conclusion that it speeds up ASP. One such article that was orginally written on ASPToday says it affects performance by 10%: http://www.plourdenet.com/writing/benchmarks1.htm
Global.asa:
Also taken from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnasp/html/asptips.asp
quote:
Tip 18: Use TypeLib Declarations for ADO and Other Components
When using ADO, developers often include adovbs.txt to get access to ADO's various constants. This file must be included on every page that wants to use the constants. This constant file is fairly large, adding a lot of overhead to every ASP page's compilation time and script size.
IIS 5.0 introduces the ability to bind to a component's type library. This allows you to reference the type library once and use it on every ASP page. Each page does not pay the penalty of compiling the constant file, and component developers do not have to build VBScript #include files for use in ASP.
To access the ADO TypeLib, place one of the following statements in Global.asa.
<!-- METADATA NAME="Microsoft ActiveX Data Objects 2.5 Library"
TYPE="TypeLib" UUID="{00000205-0000-0010-8000-00AA006D2EA4}" -->
or
<!-- METADATA TYPE="TypeLib"
FILE="C:\Program Files\Common Files\system\ado\msado15.dll" -->
Now, the inc_adovbs.asp file is much smaller than it could be so the performance benefit may be negligible. However, if you were to include this (perhaps as an optional file), it might make things easier to maintain. What I mean by that is if you come across a situation where you need a new ADO constant, you already have it.
I appreciate your willingness to listen to suggestions. |
Mark Petersen |
Edited by - mppeters on 29 April 2003 11:55:32 |
|
|
|
RichardKinser
Snitz Forums Admin
USA
16655 Posts |
Posted - 29 April 2003 : 12:01:26
|
| We attempted using #2 but too many people got errors because of it, so we implemented the current solution. |
|
|
|
snaayk
Senior Member
USA
1061 Posts |
Posted - 29 April 2003 : 12:06:28
|
Option Explicit does not initself increase performance is what dave is trying to tell you. The fact that it forces you to declare all your variables is what increases performance; read your own links and you will see this is what they are saying. In fact the ASPToday articles says the following:
For this test we will remove the Option Explicit reference and the Dim Statements for the variables. the phrase to pay close attention is the "...and the Dim Statements for the variables." Thus, not declaring the variables. It has been proven through more test, which I am sure you can find with some Googling, is that having Option Explicit will hamper performance. Why? becasue if you know that all your variable are declared and you are still checking to make sure that they are declared with every page load - yes an unneccessary check.
As far as the inc_adovbs file,I have read this as well on a few sites. But since access to the ASAx file is not guaranteed Snitz cannot useit. I myself use it on my sites. It's just asier not having to include it on every page. |
|
|
|
mppeters
Starting Member
Canada
4 Posts |
Posted - 29 April 2003 : 12:26:59
|
My apologies then. I did not know that using option explicit itself would hamper performance. I can't seem to find an article on it though. Anyone have a link to one?
That being said, try turning on Option Explicit and you'll get an unpleasant surprise that not all variables are declared! Which is completely understandable. I mean, who wants to go through the entire site checking each page for declarations? I just tried starting to do it and it's no easy job, given the number of undeclared variables.
Perhaps, as Dave said, it should be used until the last possible second in development, and then just commented out for production. |
Mark Petersen |
Edited by - mppeters on 29 April 2003 12:56:03 |
|
|
|
snaayk
Senior Member
USA
1061 Posts |
Posted - 29 April 2003 : 14:17:35
|
quote:
Originally posted by mppeters
....Perhaps, as Dave said, it should be used until the last possible second in development, and then just commented out for production.
I can't seem to locate the article now, but that was the gist of it. Use it throughout testing and before releasing to production you should remove it. Someone had done a test with and without it, we have a few benchmarkers here, maybe someone is willing to benchmark the differance?? |
|
|
|
Doug G
Support Moderator
USA
6493 Posts |
Posted - 29 April 2003 : 14:41:23
|
I don't know about the hardware, but Option Explicit certainly makes my performance faster  I always use it myself. I haven't run tests, but I believe the MSDN article quoted above.
|
======
Doug G
======
Computer history and help at www.dougscode.com |
|
|
|
DavidRhodes
Senior Member
United Kingdom
1222 Posts |
Posted - 29 April 2003 : 15:15:16
|
Isn't it that using Option Explicit makes the asp.dll check each variable to ensure it has been declared thus leading to a decerase in performance. I generally use it in development and comment it out in release.
Referencing the type library in global.asa is more efficient and easier to maintain but, like davemaxwell says and in my case also, not all hosts allow it's use |
The UK MkIVs Forum |
|
|
|
davemaxwell
Access 2000 Support Moderator
USA
3020 Posts |
Posted - 29 April 2003 : 15:50:45
|
quote:
Originally posted by DavidRhodes
Isn't it that using Option Explicit makes the asp.dll check each variable to ensure it has been declared thus leading to a decerase in performance.
That's what the article I had read said (can't find the link now, of course....). You don't notice it as much because all the variables are defined, but you're skipping that check since you don't need it if you've used it in development.
It makes a huge difference in development because asp dimming the variables is much more expensive than if you defined them yourself. |
Dave Maxwell
Barbershop Harmony Freak |
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 29 April 2003 : 21:57:26
|
Most articles I've read say to take option explicit out one your finished with the page It's exactly as DavidRhodes presented it above
If you sit and think about it for a minute it has to be slower than without it as it causes as the ASP parser to do a first pass to check all variables have an associated DIM, by removing that option explicit the parser no longer has to do this thus save some time. |
Kiwihosting.Net - The Forum Hosting Specialists
|
|
|
|
GauravBhabu
Advanced Member
4288 Posts |
Posted - 29 April 2003 : 22:58:50
|
quote:
Originally posted by Doug G
I don't know about the hardware, but Option Explicit certainly makes my performance faster I always use it myself. I haven't run tests, but I believe the MSDN article quoted above.
Ditto. |
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 30 April 2003 : 02:58:35
|
| Perception or tested though ? arguably leaving it in or taking it out we are only likely talking about nanoseconds unless on very heavily loaded servers and then you might be talking milliseconds. |
Kiwihosting.Net - The Forum Hosting Specialists
|
|
|
|
mppeters
Starting Member
Canada
4 Posts |
Posted - 30 April 2003 : 10:02:17
|
So I think it's safe to say we've established that using Option Explicit does not in itself improve speed. However, all variables should be declared, so it's good practice to turn it on during development.
Also, using global.asa for ADO constants would provide some benefit. However, it cannot be guaranteed to work for everyone so the include file needs to be used instead.
Thanks to everyone for your posts.
All things considered, would the benefits outweigh the time you'd need to spend going through each page/function/include (don't want to dim twice) and adding the variable declarations?
Other thoughts:
Is it possible to create a mod for this? I don't know how mods work.
Hey, if you want to get really crazy, it might be possible to create a page using the FileSystemObject to read the code in each page and automatically dimension the variables for you. I'm guessing you could get maybe 90% of them with a well-written script. Though it's probably not practical. I mean, how would you tell if a word is a variable? Once you determine that, is it global or local to a function/sub? Has it been declared already in a page you're including? If it hasn't, should it be declared in the include page?
Sorry about the rambling, I think I just talked myself out of it unless it already been done (?)
|
Mark Petersen |
|
|
|
bjlt
Senior Member
1144 Posts |
Posted - 30 April 2003 : 11:52:41
|
Which is better, to put the meta tag in config.asp instead of the include there or in global.asa ?
|
|
|
|
Doug G
Support Moderator
USA
6493 Posts |
Posted - 30 April 2003 : 13:55:01
|
quote:
Perhaps more important, it turns out that declared variables are faster than undeclared variables. Under the covers, the scripting run time references undeclared variables by name, every time they are used. Declared variables, on the other hand, are assigned an ordinal, either at compile time or run time. Subsequently, declared variables are referenced by this ordinal. Since Option Explicit forces variable declaration, it insures that all variables are declared and thus will be accessed quickly.
Testing disproves this?
|
======
Doug G
======
Computer history and help at www.dougscode.com |
|
|
|
Topic |
|
Topic Locked
