Interesting, this.
I need to get more speed out of some date mathematics. The following is a well known algorithm (so the way it works, is not important.
VB Code:
Public Function Julian(y As Long, m As Long, d As Long) As Long Dim jy As Long Dim ja As Long Dim jm As Long Dim intgr As Long If (m > 2) Then jy = y jm = m + 1 Else jy = y - 1 jm = m + 13 End If intgr = Fix(Fix(365.25 * jy) + Fix(30.6001 * jm) + d + 1720995) ja = Fix(0.01 * jy) intgr = intgr + 2 - ja + Fix(0.25 * ja) CGreg2Jul = intgr End Function
So, ignoring the subtleties of the 'FIX' function, I rewrote it in C and housed it in a DLL as:
VB Code:
int _stdcall Julian (int y, int m, int d) { int jy,ja,jm,intgr; if (m>2) { jy=y; jm=m+1; } else { jy=y-1; jm=m+13; }; ja = int(0.01*jy); intgr = int(int(365.25*jy)+int(30.6001*jm)+d+1720995); intgr = intgr+2-ja+int(0.25*ja); return intgr; };
I was hoping, by default, for a marvellous jump in speed, here. But I didn't get it. I tried two things:
(i) Compiled, and calling the function using a Declare stmt = virtually identical speed. On some runs the C DLL perfoms around 20% better
(ii) Through a typelib . . .
VB Code:
[ uuid(ad534fb5-794a-11da-8cd6-0800200c9a66), version(1.0), helpstring("Date Win32 Library") ] library Date { [dllname("Date.dll")] module Date_API { [entry("Julian")] long Julian ([in] int y,[in] int m,[in] int d); } }
. . . which consistently gets around 20% improvement in speed, but sometimes jumps to about 40% improvement.
I was hoping for >100% improvement in speed.
Just goes to show, that the architecture (ie how it's put together) in some cases is much more important than the raw code.
Any thoughts?




Reply With Quote