API Declarations... just curious.

[Lance]

Hi all,

I'm curious as to the technicalities of why a particular method declaring and calling is
faster than the other. The C syntax is:

\\\\\
BOOL PathMatchSpec(
LPCSTR pszFile,
LPCSTR pszSpec
);
\\\\\

In VB2005, I'm declaring and then calling an API function as such:

\\\\\
Private Declare Auto Function PathMatchSpec Lib "shlwapi" _
(ByVal pszFileParam As IntPtr, _
ByVal pszSpec As IntPtr) As Boolean

Private Function MatchSpec(ByVal sFile As String, ByVal sSpec As String) As Boolean
Dim FilePtr As IntPtr = Marshal.StringT oHGlobalAuto(sF ile)
Dim SpecPtr As IntPtr = Marshal.StringT oHGlobalAuto(sS pec)
Dim Match As Boolean
Match = PathMatchSpec(F ilePtr, SpecPtr)
Marshal.FreeHGl obal(FilePtr)
Marshal.FreeHGl obal(SpecPtr)
Return Match
End Function
\\\\\

This (the above example) runs nearly 20% faster over the course of about 190,000 calls
than declaring and calling it as such:

\\\\\
Private Declare Auto Function PathMatchSpec Lib "shlwapi" _
(ByVal pszFileParam As String, _
ByVal pszSpec As String) As Boolean

Private Function MatchSpec(ByVal sFile As String, ByVal sSpec As String) As Boolean
Return PathMatchSpec(s File, sSpec)
End Function
\\\\\

With all the marshaling in the first example, I would have thought there would have been
some significant overhead going on compared to the second example.

[Tom Shelton]

Lance wrote:

Hi all,

I'm curious as to the technicalities of why a particular method declaring and calling is
faster than the other. The C syntax is:

\\\\\
BOOL PathMatchSpec(
LPCSTR pszFile,
LPCSTR pszSpec
);
\\\\\

In VB2005, I'm declaring and then calling an API function as such:

\\\\\
Private Declare Auto Function PathMatchSpec Lib "shlwapi" _
(ByVal pszFileParam As IntPtr, _
ByVal pszSpec As IntPtr) As Boolean

Private Function MatchSpec(ByVal sFile As String, ByVal sSpec As String) As Boolean
Dim FilePtr As IntPtr = Marshal.StringT oHGlobalAuto(sF ile)
Dim SpecPtr As IntPtr = Marshal.StringT oHGlobalAuto(sS pec)
Dim Match As Boolean
Match = PathMatchSpec(F ilePtr, SpecPtr)
Marshal.FreeHGl obal(FilePtr)
Marshal.FreeHGl obal(SpecPtr)
Return Match
End Function
\\\\\

This (the above example) runs nearly 20% faster over the course of about 190,000 calls

Can you please post a complete example of this (including your method
of timing)? I am not seeing much of a difference at all. Over a
190,000 calls I'm only seeing about a .00008 second difference...

--
Tom Shelton

[Lance]

Hi Tom,

I knew you'd be the first to reply to an API question :-)

My method of timing uses:

\\\\\
Private Declare Auto Function GetTickCount Lib "kernel32" () As Int32
\\\\\

right before and after the start of the loop, then calculates the diference.

BTW, I'm an idiot and I missposted something: 190,000 returned True from the function
call, but the function iteself was called 1,040,528 times. Also, LAN conditions are
likely effecting this as well; the 20% figure I gave earlier is an average over the course
of testing on different days at different times.

FWIW, the loop is not a test loop (i.e., x = 1 to 190000) but a loop that includes
searching for all files (*.*) on a network of which 190,000 fit the sSpec and return True.
Also, the sSpec string contains 44 different file types (i.e. "*. txt; *.log; *.
doc;....." etc.). I suppose these factors may effect the results.

As for the rest of the code, it's a VB.Net-ized version of
http://vbnet.mvps.org/index.html?cod...l_multiple.htm. Not
all that much has changed from the code you see on that page, except for the types and the
declarations (which you provided in a previous answer to a posting of mine), including the
variations I posted in my original message.

Lance
"Tom Shelton" <to*@mtogden.co mwrote in message
news:11******** *************@e 3g2000cwe.googl egroups.com...

>
Lance wrote:

>Hi all,

I'm curious as to the technicalities of why a particular method declaring and calling
is
faster than the other. The C syntax is:

\\\\\
BOOL PathMatchSpec(
LPCSTR pszFile,
LPCSTR pszSpec
);
\\\\\

In VB2005, I'm declaring and then calling an API function as such:

\\\\\
Private Declare Auto Function PathMatchSpec Lib "shlwapi" _
(ByVal pszFileParam As IntPtr, _
ByVal pszSpec As IntPtr) As Boolean

Private Function MatchSpec(ByVal sFile As String, ByVal sSpec As String) As Boolean
Dim FilePtr As IntPtr = Marshal.StringT oHGlobalAuto(sF ile)
Dim SpecPtr As IntPtr = Marshal.StringT oHGlobalAuto(sS pec)
Dim Match As Boolean
Match = PathMatchSpec(F ilePtr, SpecPtr)
Marshal.FreeHG lobal(FilePtr)
Marshal.FreeHG lobal(SpecPtr)
Return Match
End Function
\\\\\

This (the above example) runs nearly 20% faster over the course of about 190,000 calls

Can you please post a complete example of this (including your method
of timing)? I am not seeing much of a difference at all. Over a
190,000 calls I'm only seeing about a .00008 second difference...

--
Tom Shelton

[Mattias Sjögren]

Lance,

I don't think it's a very good idea to involve network IO in your
benchmark. There are so many other factors that affect performance
when you involve a network connection (such as caching, network load
etc).

I tried code similar to yours on different declarations of another API
- lstrcmp - that has almost the same signature as PathMatchSpec.

Declare Auto Function lstrcmp1 Lib "kernel32.d ll" Alias "lstrcmp"
(ByVal lpString1 As String, ByVal lpString2 As String) As Integer

Declare Auto Function lstrcmp2 Lib "kernel32.d ll" Alias "lstrcmp"
(<MarshalAs(Unm anagedType.LPTS tr)ByVal lpString1 As String,
<MarshalAs(Unma nagedType.LPTSt r)ByVal lpString2 As String) As
Integer

Declare Auto Function lstrcmp3 Lib "kernel32.d ll" Alias "lstrcmp"
(ByVal lpString1 As IntPtr, ByVal lpString2 As IntPtr) As Integer

For 1,000,000 iterations timed with the .NET 2.0 StopWatch class I got
the following results

1: 882 msec
2: 198 msec
3: 1525 msec

So in this case the clear winner is declaring the parameters as String
and adding the MarshalAs(LPTSt r) attribute to avoid VB's default
MarshalAs(VBByr efStr) which causes unnecessary copying to preserve
classic VB behaviour. The third, DIY method is by far the slowest like
I would expect, since it involves the most managed/native transitions.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Lance]

Thanks for the info Mattias.

Lance

"Mattias Sjögren" <ma************ ********@mvps.o rgwrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

Lance,

I don't think it's a very good idea to involve network IO in your
benchmark. There are so many other factors that affect performance
when you involve a network connection (such as caching, network load
etc).

I tried code similar to yours on different declarations of another API
- lstrcmp - that has almost the same signature as PathMatchSpec.

Declare Auto Function lstrcmp1 Lib "kernel32.d ll" Alias "lstrcmp"
(ByVal lpString1 As String, ByVal lpString2 As String) As Integer

Declare Auto Function lstrcmp2 Lib "kernel32.d ll" Alias "lstrcmp"
(<MarshalAs(Unm anagedType.LPTS tr)ByVal lpString1 As String,
<MarshalAs(Unma nagedType.LPTSt r)ByVal lpString2 As String) As
Integer

Declare Auto Function lstrcmp3 Lib "kernel32.d ll" Alias "lstrcmp"
(ByVal lpString1 As IntPtr, ByVal lpString2 As IntPtr) As Integer

For 1,000,000 iterations timed with the .NET 2.0 StopWatch class I got
the following results

1: 882 msec
2: 198 msec
3: 1525 msec

So in this case the clear winner is declaring the parameters as String
and adding the MarshalAs(LPTSt r) attribute to avoid VB's default
MarshalAs(VBByr efStr) which causes unnecessary copying to preserve
classic VB behaviour. The third, DIY method is by far the slowest like
I would expect, since it involves the most managed/native transitions.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.