I have some more information about the Ruby/GTK+ garbage collection situation that I talked about in my previous post.
I am now all-but-convinced that the unavoidable 200+ millisecond application pauses seen in Ruby/GTK+ programs are caused by the Ruby/GTK+ bindings. (That is: not Ruby, not GTK+, but the binding between the two.)
Here’s what’s happening, to the best of my knowledge:
- At garbage collection time, Ruby gives each add-on module an opportunity to do some processing.
- During this time, Ruby expects the module to tell it which Ruby objects the module still has a reference to, so Ruby knows not to delete the object during the second (“sweep”) phase of the garbage collection.
- The problem is how the Ruby/GTK+ bindings go about finding references to Ruby objects: it loops over all GObjects and for each one requests a list of all GObject properties, then loops over those. And this process is slow.
The solution to this problem has to come from the bindings. There’s no work-around that I can think of.
What the bindings need is a fast way to provide a list of all in-use Ruby objects. Could it be smarter about where it looks for Ruby objects? Could it do reference counting? I do think this problem is solvable.
I posted about this problem to the Ruby/GTK+ forum, including short example code to reproduce the problem, but unfortunately no one has responded yet.
Until this issue is addressed in the bindings, I recommend that you do not use Ruby/GTK+ for any application where a 200+ millisecond pause would be noticeable. It continues to work great for other apps, though.
A solution for Luz
As part of my testing of the above problem, I split Luz into two parts: the Luz Editor, and the Luz Performer.
- The editor continues to use the Ruby/GTK+ bindings and suffers from pauses.
- The performer uses the Ruby/SDL bindings instead of Ruby/GTK+, it has no GUI, it simply loads and displays a Luz set fullscreen. The great news is that this works fantastically. The animation is smooth and all features work.
This is an acceptable situation to live with, until either the Ruby/GTK+ bindings are fixed or Luz becomes popular enough that people write Luz set editors using other GUI toolkits (perhaps for OSX, Windows, and some non-GTK+ toolkit on Linux).