PyGObject Hackfest Report

GNOME Foundation Sponsorship logoThe week before last I attended the GNOME Python introspection hackfest in Prague. This was the first hackfest I have ever attended, and the first time I have been sponsored to attend an open source event. It was really nice of the GNOME Foundation to reimburse my travel costs, and of Collabora to pay for the conference.

Collabora logoAll of us who attended are really thankful for Collabora paying for the usual bits, as well as our beers for the week and a traditional Czech duck dinner on the Thursday evening. I don’t think the beer expenses came out to too much because beer is really cheap in Prague and we spent most of the time working and not drinking. Nonetheless Collabora was willing to pay for whatever we drank, and the dinner too, which was absolutely delicious.

The hackfest was at BRMLab, a local hardware hacking club, and although hard to find, was a comfortable space with good internet and a great place to get work done. It was really nice meeting so many cool hackers and talk about all sorts of interesting things over dinner every night.

How I spent my time at the hackfest

I asked to attend the hackfest when J5 asked on his blog for application developers to attend. The week before the hackfest I started porting Jokosher and asking about issues on IRC. By the time the hackfest started I had met a couple of the hackers on IRC, and was getting familiar with the how the introspection bindings worked.

The first three days of the hackfest I worked on Jokosher. It was really useful having Tomeu and J5 in the same room. When I came across issues, I could ask them right there. I quickly figured out that Cairo isn’t going to be wrapped, and so static bindings for cairo should be used. In addition, GStreamer support is lacking, but it isn’t so crucial at the moment because they develop their static bindings separately. The GStreamer Python bindings will still be available for the next major release, unlike with PyGTK, where there will be no static Python bindings for Gtk 3.0.

So for those three days I concentrated only on porting Gtk, and making sure it worked with Jokosher. After getting my patches reviewed and committing them all on Wednesday I was looking for something to do for the last two days. I had run into a few problems with drawing callbacks using Gtk 3 and introspection, and I wanted to work on something less specific to Jokosher and more generally useful.

Improving startup time

At dinner someone mentioned that right now startup time with introspection is way slower than with the static bindings, even though in theory it should be quicker, because most classes are only loaded when they are accessed, and not at startup. I said I’d look into it.

On Thursday hooked up Python’s hotshot profiler and figured out where the slowest parts of the code were. It turned out that most of the time during import was spent in only two functions, both of which were responsible for setting up virtual methods. Both were also recursive, which explained why they took so much time.

In the end, I removed most of the recursion in both functions (one of them will still recurse in the case of an interface virtual method), and managed to reduce the import time with Gtk 3 from 2.5 seconds to 0.4 seconds. That is timed on my computer, with a warm startup (everything still in kernel cache). But regarless, the startup time is now slightly faster than the static bindings for either cold or warm starts.

I managed to grab a power socket on my train back to Budapest to Prague on Saturday, and cleaned up my changes a bit. Then when everyone was back on Monday and Tuesday, I got both my patches committed. If J5 also finishes up his invoke rewrite branch soon, the next release of PyGObject introspection should be much faster.

  1. John Stowers says:

    Just a clarification; PyGtk is not going to “drop the static bindings”. We will continue to support and make bug fix releases against gtk+-2.24

  2. laszlo says:

    Thanks for the clarification John. I’ve fixed the text.

  3. Thanks, the correction explains the situation perfectly now.

    Good to hear PyGObject is getting near ready for large projects!

  1. There are no trackbacks for this post yet.