ZeroC has published some performance metrics comparing Ice with TAO which is one of the fastest implementation of CORBA. In almost all areas, it seems to be not just slightly faster, but in some places massively (3-16x) faster. Quite some interesting numbers, unfortunately they have not, as near as I can determine, published the actual code used to do the benchmarks so that comparisons could be made on other hardware. Also, they compared using a loopback interface, rather than over a network, which could impact performance in some cases.
No thoughts
Slice is the interface definition language (IDL) for Ice and I’ve been having a very bizarre problem with how I was using it—something that worked fine in CORBA. I have a few struct definitions in my file:
module Foo {
struct MyStruct {
...
};
};
I keep all my “types” (or structures) in the same file, all defined at this top level module level. I then import them into each place that needs them like this:
#include <struct .ice>
module Foo {
interface Bar {
MyStruct getStruct();
};
};</struct>
You would think this works, and at least from my reading of the manual, it should, as it is possible to open and close a module and add new things into it. Unfortunately, this continually gave me an error:
sys:1: RuntimeWarning: invalid return value for operation 'getStruct'
TestApplication.py: warning: dispatch exception:
Operation.cpp:870: Ice::MarshalException:
protocol error: error during marshaling or unmarshaling
Somewhat useful, I guess, but unfortuantely it didn’t seem to help me figure it out. When I finally moved the struct definition inside the other file, everything worked. Perhaps it was my running of the slice compiler, slice2py:
$ slice2py -I. --all --output-dir ../lib/ Foo.ice
I’ll post this on the support board and see what other’s think.
Updated: Not 1 hour after posting this to the forums, I got a response from one of the ZeroC staffers that pointed out that my use of --all was not appropriate. Removing it and changing the invocation to:
$ slice2py -I. --output-dir ../lib *.ice
fixed everything up just great! That’s some great responsiveness, and I hope it’s indicative of the level of service they provide their paying customers as well.
1 thought
So I’m working on some code that requires distributing events, and I decided I’d write it in Smalltalk—mostly because I’m bored with Python, and think it’s zooming off into lala land in some ways—and since I’m using the Cincom Smalltalk, I’m using the Opentalk stuff. This is all it takes:
broker := RequestBroker newStstMcastAtPorT: 9011.
broker start.
broker objectAdaptor export: myEventProxy oid: #Events.
events := broker groupById: #Events.
After that, I have something I can now send messages to all I want. I don’t have to do anything funny, just simply things:
events categorize: #(0 1 2 3 4).
That would send the message categorize: with the array #(0 1 2 3 4) as its argument to all objectAdaptor objects that had published something for the group #Events. Note, there’s also a McastEventService, but it doesn’t actually do the kind of “events” that I’m working with, so I’m writing my own, more akin to a messaging system, not the simple event notification framework.
While this is possible in Python (with something like Pyro or better, Elvin), I can’t imagine how painful it’d be with Java or C++. Without the flexibility of a dynamic system, you’re stuck with crap like IDLs and Java RMI.
No thoughts