qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cliff Jansen (Interop Systems Inc)" <v-clj...@microsoft.com>
Subject RE: IKVMing the Java client for .Net
Date Wed, 02 Dec 2009 05:32:41 GMT
Robert Greig wrote:
> Finally, there are performance issue with managed/non-managed heap
> copies in Java that makes JNI unattractive (I don't know if this
> applies to .NET too - although I did ask the question on this mailing
> list some time ago without receiving any answer).

I'll take a stab at it now.

This can be mitigated somewhat by asking the garbage collector to pin
a managed memory location for a brief amount of time, but there are
housekeeping costs associated with that too.

In the current WCF implementation, there is a single copy between the
binary message content in managed space and the individual AMQP
message body frames in native space.  A purely native Visual C++
application would have to make that same copy.  But it would be spared
the costs of the pinning and the numerous managed to native
transitions used to monitor and control the Qpid objects that control
connections, sessions, subscriptions etc.  For very large messages,
the overhead is small.  For 100 byte sized ones it is certainly
significant.

Cliff

-----Original Message-----
From: Robert Greig [mailto:robert.j.greig@gmail.com] 
Sent: Wednesday, January 28, 2009 12:05 PM
To: dev@qpid.apache.org; cctrieloff@redhat.com
Subject: Re: IKVMing the Java client for .Net

2009/1/23 Carl Trieloff <cctrieloff@redhat.com>:

> In a discussion with the Microsoft guys, I they where thinking of using the
> C++ client, with WCF on top of that. They seem to have thought about that
> quite a bit, so it would be good to get those comments onto the list also
> around this topic.

Is this not going to suffer the same performance issues that Java has
with JNI? (I ask that as a question, not an assertion, but I had
always assumed this would apply across both platforms).

In Java there is a non-trivial performance penalty copying data from
the C heap to the Java heap and vice versa. This is one reason why
some JDBC drivers built on top of native code perform and scale much
worse than pure Java drivers (the example often benchmarked is the
Oracle driver).

RG

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org



---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message