Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

cDate() vs DateSerial() 2

Status
Not open for further replies.

Tarwn

Programmer
Mar 20, 2001
5,787
US
I was working on some revisions to an older piece of ASP code this morning and found calls to the DateSerial() function, something I had forgotten the existence of. In an attempt to see if a cDate would speed up execution I put together a quick benchmark based on some of the older benchmarks I have posted. The results may be interesting for those of you trying to optimize your code.

I have seen cDate used in many cases to build dates for the beginning or end of the current month/year/what have you. Commonly people will write this like so:
Code:
myDate = cdate(Month(Now) & "/1/" & Year(Now))

I decided to try this common "get the first day of te month" problem with cDate and DateSerial.

All of the test results here are the result of 500,000 loops run 4 times and averaged for higher accuracy.

In the end, the cDate method took 2.5 times the DateSerial method. This is not a trivial difference in the grand scheme of things. I decided to look directly at the two functions to see if the problem was the concatenation (which we all know is slow) or if the cDate function itself wa inherently slow.

The next comparison was between cDate("1/1/2004") and DateSerial(2004,1,1). With this setup cDate took 5 times the amount of time the DateSerial function took. Obviously they are taking differant inputs so they can't be used interchangeably in this case.

The last attempt was to see if I could create my own simple Cdate function that would only accept mm/dd/yyyy formatted strings and convert them using DateSerial. I doubted I would be able to create an inherently faster function that was quicker than the built in function, but I attempted two differant methods:
Code:
Function MYCDate(str)
	Dim a
	a = Split(str,"/")
	MyCDate = DateSerial(a(2),a(0),a(1))
End Function

Function MYCDate2(str)
	Dim a, b
	a = InStr(str,"/")
	b = InStr(a+1,str,"/",1)
	MyCDate2 = DateSerial(mid(str,b+1,len(str)-b),mid(str,1,a-1),mid(str,a+1,b-a-1))
End Function

In the end I was proven correct. Despite the fact that cDate() is so much slower than DateSerial, my two methods weer both slower than the cDate method by at least 50% (50% and 58% respectively).

The actual times do not matter beyond use as a comparison, but I will post the raw results:
Code:
Benchmark Results 
Method Average Low High Name 
Method #1 5.293 5.281 5.313 cDate(Month(Now) & "/1/" & Year(Now)) 
Method #2 2.102 2.094 2.109 DateSerial(Year(Now),Month(Now),1) 
Method #3 2.598 2.578 2.625 cDate("1/1/2004") 
Method #4 0.531 0.531 0.531 DateSerial(2004,1,1) 
Method #5 3.867 3.859 3.875 MyCDate("1/1/2004") 
Method #6 4.930 4.922 4.938 MyCDate2("1/1/2004")  

Times are averages from 4 runs of 500000 loops for each method.

I did not feel up to the reformatting challenge of making these easier to view, if anyone has any faster methods to do a simple cDate using DateSerial, please let me know.

I'm going to run some more if people have suggestions for test cases. Something I interested in is trying to create dates with #'s. Obviously I wonder about the speed, but I'm also curious whether that actually creates a date object or simply a variant string. You can use Date functions on strings, forcing it to do an internal date conversion, so I'm curious if there isn't a way to convert a string using #'s.

-T

01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111
The never-completed website:
 
And who said you have no spare time...

Programming today is a race between software engineers striving to build better and bigger idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook (No, I'm not Rick)

zen.gif
 
that's the first thing that came to mind to....who always says they have no spare time [lol]



___________________________________________________________________

The answer to your ??'s may be closer then you think.
Check out Tek-Tips knowledge bank by clicking the FAQ link at the top of the page faq333-3811
 
Heh, I did that on the clock. I'm making changes to an older work system that could load a few thousand records to the screen, any kind of extra optimization I can squeeze out will make a nice difference when it is outputting that data.

01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111
The never-completed website:
 
I'm actually suprised at the fact that method 2 was 4 times slower then method 4 - nice arguement for hard coding the values (and I'm not arguing for hard coding)...

Programming today is a race between software engineers striving to build better and bigger idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook (No, I'm not Rick)

zen.gif
 
When you iterate code 500,000 times each small overhead multiplies by 500,000. Method 2 has 4 extra function calls (year(), month() and twice now()), so... Still interesting.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top