cdate is slow... any alternatives?

[Eric Fleet]

In implementing the IComparer method of a listview, I found sorts by date are incredibly slow. I used a second dummy project to find out what the issue was. Code as follows simply converts two strings to two dates, and if they are not dates, uses 1/1/1900. If str1, and str2 are both valid dates, this loop runs in milliseconds. If one is not a date, the loop funds in 8 seconds. If both are not dates, then the loop runs in 16 seconds!!
Can anyone suggest a way to speed this up? I understand that type conversion can be intensive, but this is ridiculous in my opinion..

[code snippet
On Error Resume Next
For intCounter = 1 To 100
dte1 = #1/1/1900
dte2 = #1/1/1900
dte1 = CDate(str1
dte2 = CDate(str2
[Date].Compare(dte1, dte2
Nex
[end code snippet]

[Chris Morse]

On Wed, 25 Feb 2004 07:31:08 -0800, "Eric Fleet"
<an*******@discussions.microsoft.com> wrote:

In implementing the IComparer method of a listview, I found sorts by date are incredibly slow. I used a second dummy project to find out what the issue was. Code as follows simply converts two strings to two dates, and if they are not dates, uses 1/1/1900. If str1, and str2 are both valid dates, this loop runs in milliseconds. If one is not a date, the loop funds in 8 seconds. If both are not dates, then the loop runs in 16 seconds!!!
Can anyone suggest a way to speed this up? I understand that type conversion can be intensive, but this is ridiculous in my opinion...

[code snippet]
On Error Resume Next
For intCounter = 1 To 1000
dte1 = #1/1/1900#
dte2 = #1/1/1900#
dte1 = CDate(str1)
dte2 = CDate(str2)
[Date].Compare(dte1, dte2)
Next
[end code snippet]

Have you tried using the DateTime class?
Try using DateTime.Parse() to parse the date..

What I ended up doing was using the date format "YYYY-MM-DD HH:MM:SS",
which is how SQL server likes to format dates. The nice thing about
it is that it will sort correctly if you use a regular string
comparison.

// CHRIS

[Eric Fleet]

I played around a bit, and found this 'solution'. I search the string for a "/" character before trying to cdate it. It gets rid of nearly all of the non-dates before I use cdate to convert. In my mind, the fact that this works says that microsoft's function is less than optimal. I would think it would kick out anything that is obviously not a date very quickly. For those curious, here is the new code snippet

For intCounter = 1 To 100000
On Error Resume Nex
dte1 = #1/1/1900
dte2 = #1/1/1900

If InStr(str1, "/", CompareMethod.Text) > 1 The
dte1 = CDate(str1
End I

If InStr(str2, "/", CompareMethod.Text) > 1 The
dte2 = CDate(str2
End I

[Date].Compare(dte1, dte2
Nex

Note that I increased the loop by a factor of 1,000, and it now takes 1.1 seconds regardless of whether str1 is not a date, str2 is not a date, or both. Without the 'pre-check', this would have about 4 hours and 15 minutes :

Eric

[Herfried K. Wagner [MVP]]

* "=?Utf-8?B?RXJpYyBGbGVldA==?=" <an*******@discussions.microsoft.com> scripsit:

In implementing the IComparer method of a listview, I found sorts by
date are incredibly slow.

Did you try 'DateTime.Parse'/'DateTime.ParseExcact'?

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet/>

[Eric Fleet]

Thanks to you and Chris for your help. I was not aware of these functions... wasn't in the "See Also" for cdate. This is considerably faster than cdate, most likely due to its more specialized nature. It also avoids my weird code :

Thanks
Eric

[Herfried K. Wagner [MVP]]

* "=?Utf-8?B?RXJpYyBGbGVldA==?=" <an*******@discussions.microsoft.com> scripsit:

Thanks to you and Chris for your help. I was not aware of these
functions... wasn't in the "See Also" for cdate.

Always have a look at the datatype's methods!

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet/>