On Thursday 01 October 2009 02:03:50 pm you wrote: > Hi Richard, > > Your e-mail is quite long and touches various different issues (around > the same topic), so I will comment just on some items. > > * Yes, we knew about Smoke during PySide conception, as we already > told you on IRC. We also experimented with a lot of technologies, that > included even ctypes(!). Boost::Python was in fact one of that last > ones we tried. > > * Why we not picked Smoke? I can't say because I didn't try it myself > (we did a kind of distributed evaluation and shared results with the > entire team, there was a lot of things to test!), but I can talk a > little from my experience with the Gobject-based Python bindings, > while working on the PyMaemo (Python for Maemo) project. > > GObject Introspection based bindings is a new thing on the stable > distributions. At least in the last months, the latest version of > PyGtk/PyGobject bindings in Debian/Ubuntu still uses the "old" > approach, based on a tool called "codegen" that, surprise, **generates > direct Python/C "static" code** (with a little help from pygobject for > some dynamic parts). Yes, the version I checked out of git still seems to have static code generation tools in it. I was only looking at the GObject binding part which is quite old, and haven't studied how it uses gobject-introspection yet.
> This is what the Python for Maemo (the Linux based OS that runs on > Nokia's Internet Tablets) has been using for the last 4 years or so, > and it proved to be fast/small enough for many applications written in > PyGtk available for Maemo. Of course there are many places for > improvement. > > On the other hand, "dynamic" based bindings are still a untested > technology on embedded devices (If you know of any embedded device > that uses fully introspect-based bindings, specially for Python, > please let me know). I am personally interested on comparing > performance/resource usage between the two approaches and might to so > for PyMaemo at some point. As I said in my mail, Smoke was first designed in 2002, and I began the QtRuby project in July 2003. We have improved it since then, but the basic technology has worked very well. I don't get QtRuby users complaining about the dynamic nature of QtRuby because they mostly wouldn't notice. QtRuby is perceived as being pretty much on a par with PyQt as far as I know. It is slower, and doesn't work with threads, but that is more of a problem with the 1.8 version of Ruby than the bindings per se. The smoke dynamic bindings libraries are small than their static equivalents, and dramatically so once you have more than one language using them. Maybe they are a new thing for Gnome projects, but not for Qt/KDE ones. I don't see why 'small on normal linux' shouldn't be exactly equivalent to 'small on embedded linux'. The only differences I know of is that the C++ compiler might be older and not support templates so well, and doubles and floats might be different. > Please note that all this is for C code only. C++ libraries have their > own problems in embedded devices, specially the size that tends to be > a lot bigger than C ones. Yes, hence the advantage of using the much smaller smoke libraries. > Anyway, my point is that while dynamic bindings look modern and > apparently simpler/smaller, I am still a bit worried about it lacking > proper use cases in the embedded Linux-based devices (please, show me > that I am wrong! I would love to see full introspection everywhere), > and specially how much CPU overhead it introduces due to various > "table lookups" necessary for introspection. Some caching is of course > possible, but how efficient it is in terms of CPU usage (that > translates to battery usage in embedded devices)? I'm working on my third smoke based language binding right now. Other teams like PerlQt are working on smoke based bindings too. We have the implementations to test. As far as CPU usage, they are not as fast in terms of method calls as they involve table lookups as you say. But one of the main places where language bindings get hammered in Qt is for virtual method overrides, and for those there is no difference between the static and dynamic approach. The model/view classes in Qt are the worst offenders, and can slow things down. Or invoking slots and signals is going to be much the same in dynamic and static bindings - table lookups for both, no difference there. I'm not sure about battery like though, as I expect that most GUI apps would be spending most of their time idle, and so probably avoiding excessive use of QTimers might be important. It is going to be a different story for an interactive game, than for something like an app to manage your appointments. > * Boost::Python was selected amongst the others because of its > integration between C++ and the Python/C API, based on the > "intelligence" provided by the compiler that allows to > (semi-)automatically manage exceptions, type conversions and so on. > But all of this came to a price: while we achieved some impressive > performance (at least for such a initial release), the generated > bindings turned out to be _quite_ big. We attempted to improve this by > approaching some Boost::Python developers and looking for ideas (there > are other big bindings based on Boost::Python too, but not as big as > Qt+PySide) and how the compiler could help us, but still using the > modern C++ techniques requires a lot of type information to be stored > on the binary. Heavy template instantiation also did not help on the > size (although proved to be quite efficient). Well one person's '_qujte_ big' seems to be another person's 'huge' for me in this case. In terms of how exmap sees it, they use 230% of the non-shared resources at runtime compared with PyQt, according to a test that Simon Edwards performed. > Therefore we turned to play with the shiboken concept. You can find a > couple of blog posts about it written by Marcelo Lira (AKA setanta), > just search for shiboken on google (there should not be a lot of > unrelated references, as it is a random name chosen by us :) As I said in my mail I did have a look at Shiboken, but it seems to be at a very early stage (certainly the version on the public gitorious server). > * I'll not comment further on your last PyQt comment, it does not > bring any technical value IMHO. > > * Finally, we spent quite some time on the binding generator itself, > reusing work from QtScript generator and the typesystem concept. One > of PySide's strength (in my opinion) is also providing the tools to > generate bindings for any C++ library you like (although currently > limited to Qt based ones, but this changing on shiboken, made to be > generic since day one). The Qt bindings of course are our main focus. > Note that the latest code for the generator is becoming plugin based, > so Boost::Python (or shiboken, or smoke, or...) will just become a > backend for it. Ideally, this will allow *anyone* to play with > new/experimental binding concepts, and we will be able to finally and > honestly compare performance/size between the approaches. Yes, I agree the bindings generator is useful, and if Arno Rehn hadn't already developed much the same thing by the time PySide was released, then maybe we might have used it for generating the Smoke code. Because it was developed in secret the only people that might have been interested already did the same thing, and that isn't really our fault. I hope we can merge the codebases sometime and take the best bits of each perhaps. -- Richard _______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
