Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / CLR / May 2008

Tip: Looking for answers? Try searching our database.

c++ interop performance

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
devdude - 25 Apr 2008 22:26 GMT
Hello,

I'm testing out c++ interop v/s direct p/invoke and noticing that c++
interop, for my tests, are much slower then p/invoke.  I am wondering
if there are any default (security??) policies  I need to disable to
improve performance as I would prefer c++ interop.

My test is as follows:

I shuttle a few million K of data from managed to unmanaged as name/
value.  name = string, value is a byte buffer.

For p/invoke, I Marshal.AllocHGlobal the buffer on the managed side
and issue the dllimport call passing the value through a simple
StructLayout { void* data, int len }.  The string is passed by
CharSet.Ansi.

On the C++/Interop I pass it in as a byte[]/array<byte>^ on the
managed side and pin_ptr<byte> on the buffer and pass it to the
unmanaged portion as void*.  I use
Marshal::StringToHGlobalAnsi(s).ToPointer() to convert the string.

At the end of the test, p/invoke avg .006ms a call and c++/interop is .
01ms a call.

Any thoughts?

TIA
Willy Denoyette [MVP] - 26 Apr 2008 18:16 GMT
> Hello,
>
[quoted text clipped - 24 lines]
>
> TIA

Note that calling Marshal.AllocHGlobal  allocates memory from the unmanaged
heap, so, if you store your data into this buffer from unmanaged code, there
is no marshaling to be done, the buffer is directly accessible from
unmanaged code..

Mind to post your code, or at least a shot/complete sample that illustrates
the issue.

Willy.
devdude - 27 Apr 2008 02:32 GMT
On Apr 26, 1:16 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.be> wrote:

> Mind to post your code, or at least a shot/complete sample that illustrates
> the issue.
>
> Willy.

Willy,

For P/Invoke, I do the following on the managed side:

// used to shuttle the data to the unmanaged world
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi)]
public struct SomeBuffer
{
   public IntPtr data;
   public int len;
}

[DllImport("Unmanaged.dll", CharSet = CharSet.Ansi)]
  public static extern void SaveData(string name, ref SomeBuffer
data);

I then allocate the buffer ala:

       SomeBuffer CreateBuffer(byte[] value)
       {
           SomeBuffer sb = new SomeBuffer();
           sb.length = data.Length;
           sb.buffer = Marshal.AllocHGlobal(sb.length);
           Marshal.Copy(value, 0, sb.buffer, sb.length);

           return sb;
       }

and invoke SaveData() with a created SomeBuffer to house the value
byte array.

For C++ Interop, on the managed (c++/cli) side, the function is:

void SaveData( String^ name, array<byte>^ value)
{
       localName =
(char*)Marshal::StringToHGlobalAnsi(name).ToPointer();  // marshal the
name
    pin_ptr<byte> ptr = &value[0];  // pin the value buffer

    SomeBuffer sb;

    sb.buffer = (void*)ptr;
    sb.length = bytes.Length;

    unmanagedImpl->SaveData( localName, &sb);  // issue the unmanaged
call

       Marshal::FreeHGlobal(IntPtr(localName));  // free the
marshalled string buffer
}

Assume the unmanaged SaveData method copies the incoming SomeBuffer
data to process in both approaches and that the prototype is:

void SaveData (LPCSTR name, SomeBuffer* value);

Thanks
Willy Denoyette [MVP] - 27 Apr 2008 20:01 GMT
> On Apr 26, 1:16 pm, "Willy Denoyette [MVP]"
> <willy.denoye...@telenet.be> wrote:
[quoted text clipped - 63 lines]
>
> Thanks

I don't see how CreateBuffer relates to the other functions, you need to
post a complete runable sample.
Anyway, If CreateBuffer is used in the PInvoke case, then the Interop case
should be quite a bit faster than the PInvoke case, you don't copy from
managed to unmanaged in the Interop case, you just pass a pointer to the
pinned array, while in the PInvoke case you copy the managed array to
unmanaged and pass a pointer to this unmanaged array.

PInvoke should be as fast as C++ Interop, if you don't copy, but instead
also pass a pinned pointer.

Willy.
Ben Voigt [C++ MVP] - 01 May 2008 22:01 GMT
> For C++ Interop, on the managed (c++/cli) side, the function is:
>
[quoted text clipped - 3 lines]
> (char*)Marshal::StringToHGlobalAnsi(name).ToPointer();  // marshal the
> name

using an HGLOBAL here is unnecessary, I would instead call PtrToStringChars
and convert.  By using a stack buffer you can save the allocate/deallocate
time, and you can always fall back to dynamic allocation if your static
buffer isn't bug enough.

Besides, if that function really is returning an HGLOBAL, you'd need to call
GlobalLock to get a pointer.  Let me check the docs...

Oh, brilliant.  Microsoft calls the function that wraps LocalAlloc (which
returns an HLOCAL) Marshal.AllocHGlobal.  Who needs obfuscation when you
have APIs designed like that?

Also, what /clr:xyz option are you compiling with?

> pin_ptr<byte> ptr = &value[0];  // pin the value buffer
>
[quoted text clipped - 16 lines]
>
> Thanks

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.