Al
Sat May 10 11:33:06 CDT 2008
"Alex K. Angelopoulos" <aka(at)mvps.org> wrote in message
news:%23tq4SaHsIHA.5580@TK2MSFTNGP04.phx.gbl...
> Hitching a ride here... ;)
Welcome aboard!
> Basically, what they said. I played around with this a lot about 5-6 years
> ago - made some posts on obscure parts of it to this and the WSH
> newsgroup, but most of it is heavy wading with little useful results. Here
> are a few points that may have some value.
>
> + First of all, what Al said about structuring it ironically is the best
> way to gain performance in the end. Well-structured code is easy to follow
> and extend without jumping through all sorts of hoops that add performance
> problems and hidden bugs.
One day I will write a book about how to structure script code "ironically"!
;-)
> + Generally speaking, there is an overhead cost to creating a new scope,
> be it a function or a class, but the mere act of creating the scope is
> fairly rapid. I compared a generic function that just returned an empty
> value written in script and written as a method of a compiled component,
> and not surprisingly, the script function was slower by a factor of two -
> most likely due to scope creation. Even that was miniscule, and on a
> modern PC is difficult for me to measure - roughly 3 microseconds in
> script on a dual core AMD 2600+. You can trim this down by explicitly
> declaring all variables and using Option Explicit in the script as well.
Useful information, however I find that factor of two rather flattering
towards the scripted function. The OP should also realize that moving some
of his code into compiled components will not cut the overall run-time of
his script in half. If 2% of the runtime of the script is taken up with
calling a function, that will reduce that part of the "time cost" to 1%,
thereby speeding up the overall operation of the script by a whopping 1%
(100% ==> 99%).
> + Object creation is pretty expensive, more expensive than calling a
> function, even though calling into an object is cheaper. The MOST
> expensive way to create an object is to use WScript.CreateObject or
> Server.CreateObject instead of the native CreateObject in VBScript. This
> is due to extra things done for event creation I believe; the native
> CreateObject generally chops a third off of creation time.
A very useful observation, and one I was not aware of.
> This is most important if you need to continually create objects, and
> also means that hanging on to objects is a viable way of shaving time if
> you really need to.
Another useful observation. Unfortunately, this can result in reducing the
"structure" of the script by introducing more global object variables if not
done in a disciplined manner.
/Al
> + The critical choice between using functions and classes comes down to
> one thing: does the function need to perform the same tasks repeatedly? If
> you need to recreate an object and declare a couple of constants each time
> you call a function, you're going to have the scoping and creation
> overhead on each function call. If you do this consistently a couple of
> times or more in each run of the code, then you're already at the point
> where pushing the code over into a class gives you a performance gain.
> This is actually an ideal situation because classes are actually designed
> to simplify repetitive complexity.
>
> "Al Dunbar" <AlanDrub@hotmail.com.nospaam> wrote in message
> news:elGD4wgrIHA.3780@TK2MSFTNGP03.phx.gbl...
>> I agree. If you need extreme speed, use a compiled language. If a
>> scripting language will do the job, structure it in such a way as to save
>> time in the development and maintenance phases rather than trying to
>> tweak it to speed it up in the execution phase.
>>
>> /Al
>>
>> "Tim Williams" <timjwilliams at gmail dot com> wrote in message
>> news:OzNdpIVrIHA.3900@TK2MSFTNGP05.phx.gbl...
>>>I don't think it's going to make any difference. You're already creating
>>>a bunch of objects (connections, recordsets, etc).
>>>
>>> If in doubt though, it's easy to test.
>>>
>>> Tim
>>>
>>> "atwork8" <atwork8@discussions.microsoft.com> wrote in message
>>> news:6C05787C-FFCE-44C5-8644-BDEBA08D4490@microsoft.com...
>>>> Hi Guys,
>>>>
>>>> Thanks for the help :o)
>>>>
>>>> The example I provided was just for illustration . I really just wanted
>>>> to
>>>> know if i would see a significant performance difference in an asp
>>>> application that was written in classes rather than include files with
>>>> functions... all else aside collisions etc
>>>>
>>>> What do you think?
>>>
>>>
>>
>>