ANN: IceQt code repository

[ctennis]

I've started a code repository at google to keep some of the utilities I wrote that help to bridge Ice and Qt together.

iceqt - Google Code

The first small project that's available is slice2qt:

http://iceqt.googlecode.com/files/sl..._0.1.0.tar.bz2

slice2qt is a direct clone of slice2cpp (from Ice 3.2.1), with a few notable exceptions:

• dictionaries are mapped to QMap instead of std::map
• sequences are mapped to QList instead of std::vector
• string and wstring are mapped to QString

slice2qt should allow you to work with native Qt types without having to worry about handling the conversions.

It's definitely alpha quality, so caveat emptor. It requires no patching or changes to Ice. You just need a recent version of Qt to build it.

I'm sure there are things that are broken, so be careful. I haven't researched heavily into string conversions to make sure that all cases work. And I know that AMI/AMD isn't working currently as it pertains to strings.

Anyway, please feel free to post on this thread if you find it useful or have suggestions for things to change. I'll be posting some more of the Qt/Ice bridging code soon.

Caleb

[JShah]

Hi,

Do you have plans for a Ice endpoint implementation using QtSharedMemory ?

This can make inter-process / intra-process(in-process, cross language a la Microsoft COM) much more simple without the overhead of sockets.

Regards,
Jitendra

[ctennis]

I hadn't thought about it, but it's a pretty neat idea. I'm not sure what additional IPC mechanisms are going to be included in 4.4, but QtSharedMemory is only available as a solution to commercial holders as of right now, so I don't know how many people would find it useful.

Something to definitely investigate though.

[JShah]

Hi,

I guess I was only using QtSharedMemory as an example of a shared memory component that could be used for (local machine) IPC. Having an efficient mechanism with Ice for intra-process and cross language would mean, for example, the end of Microsoft COM headaches - no COM IDL and COM marshalling and COM threads. Now, that would be a very big feature of Ice, if it were implemented.

Thoughts?

Regards,
Jitendra

[marc]

Just to clarify: iceqt is not a ZeroC development, but is provided by one of our users. (Many thanks to Caleb!)

As for shared memory transports, this has been discussed before here in these forums, for example, here:

What feature would you like to see most in Ice?

We have no plans to implement any form of shared memory transport, since it would be a very intrusive change, and would only provide performance benefits for very large data transfers, but not for latency. (This is not theory; I implemented a shared memory transport in other middleware products before.)

[JShah]

Hi Marc,

Thanks for the reply.

I do realise that the Qt component is a community effort.

In the referenced post it was said that there are performance gains for IPC on a single machine. Do you know what performance gains can be expected in this scenario? Is it comparable to, say, COM? Even if it is comparable, Ice is way way better an interfacing environment that COM :-) Or, maybe there is a better/smarter way with Ice for achieving cross-language, in-process communication - any ideas will be appreciated.

Regards,
Jitendra

[marc]

I'm afraid I don't have any data available. However, from my past experience, there is a performance gain if you transfer large amounts of data, but there is no performance gain with respect to latency (since you still need a pipe-like IPC mechanism to notify the receiver about new data being available, plus locking overhead for the shared memory).

[ctennis]

Also note that while I find the problem interesting from an academic standpoint, I'm not on Windows so it's not really solving much of a problem for me.

However, this type of thing would make for good inclusion in this project, if someone was inclined to pursue it.

[michi]

Note that Ice already achieves transfer rates of several hundred megabits per second on run-of-the-mill hardware. If an application sends that much data around, it doesn't just transmit the data, it also has to do something with the data. And that is likely to be the dominant part of the end-to-end processing (such as writing the data to disk, applying some transform, or whatever).

In other words, making the transfer faster is unlikely to yield much of an overall improvement because the transfer is unlikely to account for more than a few percent of the overall cost.

Cheers,

Michi.