CODEWITHSUNDEEP
vb.netperformancevbaoptimization
galois
galois

Reputation: 142

VBS automatic optimization

I am running a pretty simple VB program that solves the Project Euler Problem 2 and I want to time the performance. My approach is:

StartTime = Timer()
Set streamer = CreateObject("Scripting.FileSystemObject")
Set writingWriter = streamer.GetStandardStream(1)
Dim n, nIterations, Temp1, Temp2, Collector
n = 4000000
nIterations = 0
Temp1 = 0
Collector = 0
Temp2 = 1

Do
    Fib = Temp1 + Temp2
    Temp2 = Temp1
    Temp1 = Fib
    Select Case Fib Mod 2
        Case 0
            Collector = Collector + Fib
    End Select
Loop Until Fib > n
EndTime = Timer()
writingWriter.WriteLine("Solution is: " & Collector)
writingWriter.WriteLine("Code took " & EndTime - StartTime & " to execute")

The first time I ran the code I got the following output (my input is also included):

C:\Dev\cscript program.vbs
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

Solution is: 4613732
Code took 0.015625 to execute

Each subsequent execution (not changing anything) gives me the following:

C:\Dev\cscript program.vbs
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

Solution is: 4613732
Code took 0 to execute

Can someone explain what is going on here? It seems like the Windows Console has stored the value of Fib and is simply recalling it upon execution of the code. A friend running something similar (although he's using VBA) got the same result - each of his subsequent executions experienced a reduction in run-time.

Please note: I know this is a pretty simple approach, I'm just trying to get a feel for VB. Not a huge fan so far.

Upvotes: 2

Views: 647

Answers (2)

redhotspike
redhotspike

Reputation: 1096

You answered your own question:

It seems like the Windows Console has stored the value of Fib and is simply recalling it upon execution of the code.

If you're not clearing Fib before you exit and you leave the console open, it is still somewhere in temporary memory.

A fix is to do:

StartTime = Timer()
Set streamer = CreateObject("Scripting.FileSystemObject")
Set writingWriter = streamer.GetStandardStream(1)
Dim n, nIterations, Temp1, Temp2, Collector
n = 4000000
nIterations = 0
Temp1 = 0
Collector = 0
Temp2 = 1

Do
    Fib = Temp1 + Temp2
    Temp2 = Temp1
    Temp1 = Fib
    Select Case Fib Mod 2
        Case 0
            Collector = Collector + Fib
    End Select
Loop Until Fib > n
EndTime = Timer()
writingWriter.WriteLine("Solution is: " & Collector)
writingWriter.WriteLine("Code took " & EndTime - StartTime & " to execute")
streamer = NULL
writingWriter = NULL
Fib = 0

Upvotes: 0

Daniel
Daniel

Reputation: 13122

The issue is not Fib. Though you do not declare it, it uses the default value as soon as it is used in a calculation. Once your script ends, it goes out of scope. The main bottleneck area for your program is this:

Set streamer = CreateObject("Scripting.FileSystemObject")
Set writingWriter = streamer.GetStandardStream(1)

Once it runs the first time, it is able to perform the same action much faster shortly there after probably due to data cached in RAM.

The actual calculations that you are doing in your Do loop happen so quickly that your timer is insufficiently precise to distinguish the time. You may find some of the information on this question: What can cause a program to run much faster the 2nd time? interesting. If you google something like "program runs faster the 2nd time", you will see a lot of responses indicating caching as the culprit.

Upvotes: 1

Related Questions