Now that there is a final release of QtJambi, I've downloaded it and had a good look at the sources. I'm happy to report that it looks very well written, very thorough and with much attention paid to issues such as performance tuning and working well with Java threads.
I do wonder why the team have chosen to totally reimplement slots and signals in Java though - I personally prefer the approach taken in QtRuby and Qyoto where QMetaObjects are constructed at runtime that are identical to the C++ equivalents, and the C++ side can't tell the difference. The QtJambi approach means that it will be very hard to implement bindings for the QtDBus classes, without a complete rewrite of the code in Java. Similarly, I think scripting language support or testing toolkits depend on using QMetaObjects to invoke slots via runtime introspection, and a different mechanism will be need for scripting QtJambi apps.
QtJambi has a Java version of the colliding mice QGraphicsView example, and I've been comparing it with the original C++ version, along with the QtRuby and Qyoto/C# ones. I just used the 'time' command from the command line, and ran the example for one minute with each language. I had a look at the memory consumption with 'top' too.
C++ used about 10s of mill in a minute on my MacBook, and according to top it took up 15.6Mb of virtual memory, 7.3Mb of resident and 6.2Mb of shared memory. Here are the memory figures from top with the ratio to the C++ value in brackets for the bindings languages:
- C++ virtual: 15.6Mb resident: 7.3Mb shared: 9.9Mb
- QtJambi (java-6-sun-1.6) virtual: 239Mb (15x) resident: 46Mb (6.27x) shared: 20Mb (3.24x)
- QtRuby virtual: 33.2Mb (2.13x) resident: 16Mb (2.18x) shared: 9.9Mb (1.6x)
- Qyoto virtual: 45Mb (2.88x) resident: 17Mb (2.32x) shared: 12Mb (1.94x)
So QtRuby and Qyoto/Mono use about twice the memory of C++, and QtJambi uses twice as much again. Next I divided the 'real time' by the 'user time' plus 'system time' figures, and calculated the mill consumption relative to C++:
- QtJambi (java-6-sun-1.6) 1.8 times slower
- QtRuby 4.1 times slower
- Qyoto 5.0 times slower
We haven't done much performance tuning for the Qyoto bindings yet, and it may be possible to speed them up and beat ruby. We've been concentrating on getting them functionally complete and reasonably stable rather than as fast as possible, and so it's slightly unfair to measure before a first release. However, I've found that unless you write graphics intensive apps like the colliding mice one it doesn't actually matter and a UI written in QtRuby or Qyoto usually feels just as responsive as a native C++ one.
I haven't got a current version of PyQt to try the same test, but I would expect it to be pretty much as fast as QtJambi and consume about the same memory as QtRuby or Qyoto though.
Syndicate Blogs
Update: PyQt colliding mice performance
I've just tried PyQt with the colliding mice example, and it is about 2.35 times slower than C++. The memory consumption is the lowest of all the bindings according to the (inaccurate and meaningless) top tool with 26.7Mb of virtual, 11Mb resident and 8.8Mb shared. If it is possible to compile python with PyQt, I assume it would be faster still.
Minor tweak improves PyQt colliding mice further
The QtJambi version of the colliding mice pre-allocates the QRectF to return from QGraphicsItem::boundingRect(), and this is a significant optimization because boundingRect() is called frequently. I applied the same improvement to the PyQt colliding mice and it speeded up the python version, making it about 1.9 times slower than the C++. So that makes PyQt about the same speed as QtJambi, and according to the unreliable top tool, PyQt uses a quarter of the memory of Java/QtJambi. Interesting.
def __init__(self):
...
self.adjust = 0.5
self.bRect = QtCore.QRectF(-20 - self.adjust, -22 - self.adjust,
40 + self.adjust, 83 + self.adjust)
...
def boundingRect(self):
return self.bRect
How to measure memory usage
http://ktown.kde.org/~seli/memory/
Numbers from top usually don't mean a thing (or you actually do know what they mean?).
Re: How to measure memory usage
Thanks for the link - I'll try exmap when I can get it to work - I haven't managed to build the kernel module yet.
I was really more interested in how much mill the bindings used compared with C++. But I think the top figures give at least some clue as to the relative memory usages. The QtRuby and Qyoto bindings both use the same Smoke shared library and that is about half the size of the QtJambi libs. So the comparative memory usage situation is more complicated if you want to use more than one binding.
Well, the memory situation
Well, the memory situation is even more complicated of course because you want to know what the _bindings_ take up. I expect that the memory usage of the Java application for example has nothing to do with the size/memory usage of bindings but more with the fact that just starting the VM it will already take up a lot of space.
But if you are making a Java application you are already taking that hit and you have already decided that you don't mind so much about the memory usage.
You could try taking out all the GUI code and see how much memory each application takes to get some idea how much is taken up by the bindings, but I guess it will be a very rough figure.