• quote:


    Philip, I took some time and tested your function against DateDiff-DateAdd.

    CREATE FUNCTION dbo.fnDateOnlyBinary

    (@Date datetime)

    returns datetime

    AS

    BEGIN

    RETURN cast(substring(cast(@date as binary(8)),1,4) + 0x00000000 as datetime)

    END

    CREATE FUNCTION dbo.fnDateOnly_DateDiff

    (@Date datetime)

    returns datetime

    AS

    BEGIN

    RETURN DATEADD(d,DATEDIFF(d,0,@Date),0)

    END

    Here were the results on a million dates.

    --Time: 55

    --CPU: 13312

    --IO: 116

    select top 1000000 dbo.fnDateOnlyBinary(DT)

    From #Date

    --Time: 55

    --CPU: 11063

    --IO: 234

    select top 1000000 dbo.fnDateOnly_DateDiff(DT)

    From #Date

    Your function used about 25% more cpu cycles, but only half the IO. It appears that Datediff and DateAdd cost IO but save a little on CPU, while casting and substring costs no IO and more CPU.

    I'm thinking I'll replace my current "day only"

    function with this one, as IO is a bottleneck for us. Of course, even the datediff-dateadd method is better than the cast-convert I'm using now.

    Good stuff.


    I tested this yesturday while waiting for a return from an Oracle system and found both methods to have almost exact comparison even when the system cache was cleared or the server restarted. Sometimes the DATEADD/DATEDIFF method came up a hair better on duration but both gave (at least on my test system) almost exact same out for CPU, IO and Duration. I tested with datasets of 100, 1000, 10000, 50000, 1000000, and 10000000 and all were neck and neck. I will try to capture the results when I hae a chance for record and post.