alternatives to p/invoke?

[Chris]

We are using SQLite.net in an application but getting a bottleneck at
the data access layer (it has been profiled). This is clearly because
p/invoke takes 5 to 10 times longer than it does calling the function
straight from C/C++ code.
Is it possible to write a wrapper in Managed C++ that provides a managed
interface to the SQLite API, but still accesses the SQLite API directly
(without using p/invoke)?

Chris

 

[Willy Denoyette [MVP]]

| We are using SQLite.net in an application but getting a bottleneck at
| the data access layer (it has been profiled). This is clearly because
| p/invoke takes 5 to 10 times longer than it does calling the function
| straight from C/C++ code.
| Is it possible to write a wrapper in Managed C++ that provides a managed
| interface to the SQLite API, but still accesses the SQLite API directly
| (without using p/invoke)?
|
| Chris

That won't help either, still you have to transition from managed code to
unmanaged code and back.
Did you try to apply the [SuppressUnmanagedCodeSecurity] attribute to your
PInvoke declaration?
This will reduce the overhead of a security check when transitionning.


Willy.

 

[Michael C]

Is it possible to write a wrapper in Managed C++ that provides a managed
interface to the SQLite API, but still accesses the SQLite API directly
(without using p/invoke)?

Of course, it's also not difficult, a wizard will create the project and
class for you.

Michael

 

[Chris]

| We are using SQLite.net in an application but getting a bottleneck at
| the data access layer (it has been profiled). This is clearly because
| p/invoke takes 5 to 10 times longer than it does calling the function
| straight from C/C++ code.
| Is it possible to write a wrapper in Managed C++ that provides a managed
| interface to the SQLite API, but still accesses the SQLite API directly
| (without using p/invoke)?
|
| Chris

That won't help either, still you have to transition from managed code to
unmanaged code and back.
Did you try to apply the [SuppressUnmanagedCodeSecurity] attribute to your
PInvoke declaration?
This will reduce the overhead of a security check when transitionning.

Thats what I wanted to know.
I haven't tried using SuppressUnmanagedCodeSecurity, but I'll try that
and see kind of effect it has.

Thanks,

Chris

 

[Michael C]

That won't help either, still you have to transition from managed code to
unmanaged code and back.

Won't you have greater control over the process in C++ and also be able to
remove some of the checks that C# would do, hence make it faster.?

Michael

 

[Willy Denoyette [MVP]]

| > That won't help either, still you have to transition from managed code
to
| > unmanaged code and back.
|
| Won't you have greater control over the process in C++ and also be able to
| remove some of the checks that C# would do, hence make it faster.?
|
| Michael
|
|

Not really, the process is exactly the same when you
'SuppressUnmanagedCodeSecurity' when using PInvoke.
Whenever a thread transitions into unmanaged world the run-time has to
perform a number of housekeeping tasks, like signaling the GC that he's
leaving for a while, so that the CLR doesn't have to stop this thread when
he starts a GC sweep. Argument marshaling is another thing that must be
done, but that's the same when you are using C++ interop, the only advantage
you have with C++ interop is that you can refine the argument marshaling,
but this highly depends on the type and size of the arguments.
When a thread returns, there is the same overhead for both methods, that is,
marshaling the return and tell the GC the thread is back.
Overall, the overhead is something like 70-80 instructions when
'SuppressUnmanagedCodeSecurity' is off (suppressed), while the overhead is
~150 instructions when it is on, this on v2 of the framework, this is
somewhat higher than it was on v1.x.

Willy.