poor i/o performance in thread parallel to Gtk.main (time overhead can be as bad as 2500%)

Bug #670743 reported by Pedro Pedruzzi
76
This bug affects 15 people
Affects Status Importance Assigned to Milestone
ruby-gnome2 (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: ruby-gnome2

rubyripper [1] is performing poorly in maverik x86-64 (up-to-date). They have an open issue for this [2].

Apparently there is nothing wrong with rubyripper. So I managed to reduce it to a small test case. It is based in the very first ruby-gnome2 example I could find.

The test function reads 3 MB from /dev/zero. This function is called from a new thread.

This is done 3 times. Before the call to Gtk.main, during it (from a button callback signal) and after it.

These are the times for each one (in seconds).
0.004285
9.689063
0.021076

Something is wrong.

Test code follows.

[1]
http://code.google.com/p/rubyripper

[2]
http://code.google.com/p/rubyripper/issues/detail?id=348

--
#!/usr/bin/env ruby

require 'gtk2'

def simpleRead
 puts "simpleRead begin\n"
 index = 0
 file = File.open("/dev/zero", 'r')
 while (index < 3 * 1024 * 1024)
  file.read(16 * 1024)
  index += 16 * 1024
 end
 file.close()
 puts "simpleRead end\n"
end

def newThreadSimpleRead
 Thread.new do
  require "benchmark"
  puts Benchmark.measure { simpleRead }
#simpleRead
 end
end

button = Gtk::Button.new("Hello World")
button.signal_connect("clicked") {
 newThreadSimpleRead
}

window = Gtk::Window.new
window.signal_connect("delete_event") {
 puts "delete event occurred"
 #true
 false
}

window.signal_connect("destroy") {
   puts "destroy event occurred"
      Gtk.main_quit
}

window.border_width = 10
window.add(button)
window.show_all

newThreadSimpleRead
STDIN.readchar

Gtk.main

newThreadSimpleRead
STDIN.readchar

Revision history for this message
Sebastian Thürrschmidt (thuerrschmidt) wrote :

Same thing here. Rubyripper (GTK) used to work very well in Karmic, where a two-pass CD rip to flac would take about 20 minutes on average. Then in Lucid and now in Maverick, the exact same process may take up to two hours or more, with long pauses in between tracks during which Rubyripper does esentially nothing.

The bug affects the older Rubyripper packages from aheck's ppa (https://launchpad.net/~aheck/+archive/ppa) as well as the more current packages from debian-multimedia (http://www.debian-multimedia.org/dists/unstable/main/binary-amd64/package/rubyripper.php). The workaround suggested in [2], locally installing ruby 1.9 plus gtk2 bindings, is rather complicated and didn't ultimately work for me, for whatever reason.

A working Rubyripper would be much appreciated, ideally one from universe.

Changed in ruby-gnome2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Daniel Dietrich (shaddowy2) wrote :

The issue was fixed some time ago in Rubyripper. Further details can be found in the the bugreport at https://code.google.com/p/rubyripper/issues/detail?id=348

Changed in ruby-gnome2 (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.