Hi all,
I’ve not maintained ruby-gnome2 for a long time.
So, I decided to hand my work over to Kouhei S…
I hope you help him well and make ruby-gnome2 better.
Best Regards,
Masao
–
.:% Masao M.[email protected]
Thanks for your work up until now, Masao. Kouhei, welcome!
I’d like to humbly suggest an area that could use some love in the
bindings: garbage collection!
The problem is that once the ruby-gnome bindings are loaded, suddenly
normal Ruby garbage collection takes a LONG TIME, and this makes
Ruby/GTK+ a bad choice for anything that does any sort of animation,
because long pauses make animations skip. This problem is the only
reason that I recommend Python/GTK+ to people, and I hate to send
people away from Ruby!
More information here:
Perhaps a short-term solution: allow the application to turn off
support for storing Ruby objects exclusively in a GTK+ GUI. So this
would mean the bindings wouldn’t have to do any garbage collection at
all. Maybe I’m missing something, but I don’t think I’ve ever stored
any Ruby objects exclusively in the GUI. We should definitely keep
the current behavior as the default, but it would be nice for the
application to have the option.
What do you all think?
-Ian
Am Donnerstag, den 13.03.2008, 13:45 -0200 schrieb Ian McIntosh:
The problem is that once the ruby-gnome bindings are loaded, suddenly
normal Ruby garbage collection takes a LONG TIME, and this makes
Ruby/GTK+ a bad choice for anything that does any sort of animation,
because long pauses make animations skip.
Hi,
That is not a such big problem.
I’m the author of Klötzle, a stop-motion animation program. And in this
i have also a video preview. This works very well.
The only thing you have to do is, that you should not rely on normal
cycles of the garbage collector, but to trigger it periodicaly by your
self.
Cheers, detlef
Hi Masao,
I want to thank you for the great work you have done for ruby gnome!
My best wishes for the future and i hope we will read here again.
Cheers, detlef
Am Donnerstag, den 13.03.2008, 23:43 +0900 schrieb Masao M.:
Unfortunately, triggering the GC process periodically is not really an
acceptable solution:
If you want to generate 72 frames per second (something Ruby without
Ruby-Gnome bindings is capable of doing), that means you need a new
frame every 14ms. That makes it hard to schedule a ~200ms pause.
Perhaps you don’t see the problem in your app because the GUI isn’t as
big, or your CPU is faster?
Just by requireing the Ruby-Gnome bindings, GC time goes from ~2ms to
~56ms in my tests. That is enough to still do about 12 frames per
second smoothly (on a 1.2ghz machine). But try doing 72 fps on the
same box. Or try doing 24 FPS on a handhelp/microlaptop/OLPC. The
hardware can do it, Ruby can do it, Ruby-GNOME can’t do it. It’s a
real problem.
Could you time the GC process in your app and report back here with
the result? There’s some code to do that here:
Am Donnerstag, den 13.03.2008, 15:24 -0200 schrieb Ian McIntosh:
Unfortunately, triggering the GC process periodically is not really an
acceptable solution:If you want to generate 72 frames per second
No one needs this 
(something Ruby without
Ruby-Gnome bindings is capable of doing),
Afaik the problem is how much data you will free with every GC run. Some
time ago this problem was discussed on the ruby mailing list. There were
some people, who had the same problem with big ruby objects (not ruby
gnome). If i remember right the consens was, that it is a problem in
rubys GC.
hardware can do it, Ruby can do it, Ruby-GNOME can’t do it. It’s a
real problem.Could you time the GC process in your app and report back here with
the result?
Sorry, but i can’t do it for now, cause all the test data i have has
such big frames, that it won’t get about 12 fps at all. For more my
computer is to slow. To generate other test data i don’t have the time
now…
Masao,
Thank you for your hard work and your great contribution to free
software and Ruby.
All the best,
Mathieu
2008/3/14, Detlef R. [email protected]:
Masao,
A heartfelt thank you for contributing so much of your time and
expertise to
such a great project that tens of thousands of people use. If you ever
come
to the UK then I’d love to buy you some beer 
- Andy.
On Fri, Mar 14, 2008 at 1:12 AM, Mathieu B.
[email protected]
13 mar 2008 kl. 15.43 skrev Masao M.:
Hi Masao,
I want to express my gratitude for the work you have done. I hope life
is treating you well and that you have other interesting projects to
keep you busy.
Welcome as well to Kouhei and a big thanks for stepping up to the task.
Cheers,
Mikael H.
.:% Masao M.[email protected]
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
ruby-gnome2-devel-en mailing list
[email protected]
ruby-gnome2-devel-en List Signup and Options
–
Imendio AB, http://www.imendio.com
Hi,
In [email protected]
“Re: [ruby-gnome2-devel-en] Maintainer changed” on Thu, 13 Mar 2008
13:45:53 -0200,
“Ian McIntosh” [email protected] wrote:
Perhaps a short-term solution: allow the application to turn off
support for storing Ruby objects exclusively in a GTK+ GUI. So this
would mean the bindings wouldn’t have to do any garbage collection at
all. Maybe I’m missing something, but I don’t think I’ve ever stored
any Ruby objects exclusively in the GUI. We should definitely keep
the current behavior as the default, but it would be nice for the
application to have the option.What do you all think?
I think that we need to profile where is the bottle neck
before trying a new idea.
Thanks,
kou
Afaik the problem is how much data you will free with every GC run.
This is not the problem. Please see the blog posts I’ve linked to.
Notice how the object count doesn’t go down (significantly) between GC
runs:5173 objects, 0.056349 GC time, 5169 remain
I have added a photos and videos classifier in my http://booh.org/
application. One of the aims is to be able to navigate between photos
and videos as FAST as possible with the keyboard, so I perform
preloading of neighborhood photos and videos. I constantly monitor the
RSS taken by the program in order to free distant preloaded data
before exhausting the computer’s memory. Because of the GC “problem”
when using rg2 (not running by itself), I trigger the GC before
freeing the data (it’s impressive to see the speed at which the RSS
grows, and how it can be reduced by triggering the GC).
I also experience your problem: when classifying 750 photos and
videos, after a while the program has a lot in memory, triggering the
GC takes about 350 ms (74000 => 37000 objects, on a p4 2.8 GHz, 390 MB
of RSS), so the program is completely unresponsive during each GC run
and 350 ms is VERY noticeable when you’re waiting for a photo to show
up – this is very bad because actually what’s blocking is a
preloading process, e.g. by essence it is not of a big priority: the
navigation between already preloaded photos and videos is the priority
task, and the wait is very annoying.
Now to the future: it seems that this problem isn’t a priority for
main rg2 developers; would you have time to investigate and propose a
patch or a solution?
–
Guillaume C. - Guillaume Cottenceau
Perhaps a short-term solution: allow the application to turn off
support for storing Ruby objects exclusively in a GTK+ GUI. So this
would mean the bindings wouldn’t have to do any garbage collection at
all. [snip]What do you all think?
I think that we need to profile where is the bottle neck
before trying a new idea.
Attached is a Sysprof profile of Luz (a ruby-gnome2 application)
forcing garbage collection repeatedly. Also attached are two
screenshots taken of the same sysprof data, for easy consumption.
The problem I’m trying to solve is that each GC run takes over 100ms,
preventing smooth graphics animation.
These methods seem to stand out (shown here with relative “Self” times):
g_object_class_list_properties / g_param_spec_pool_list (7) /
pool_depth_list (4) / g_type_is_a (11)
Any thoughts for improving this situation? It would be far better for
Luz if GC took more CPU time overall, but with shorter spikes.
(Not pausing the application for very long at a time.)
I’m happy to dig deeper and do more testing/profiling if needed.
Best,
-Ian
I understand that it works OK for your use-- on a fast CPU and with a
very, very low frame-rate requirement. But with a slower CPU or
higher FPS: Python = fast, Ruby = fast (especially 1.9!), Python-GTK =
fast, Ruby-GTK = sloooow.
Afaik the problem is how much data you will free with every GC run.
This is not the problem. Please see the blog posts I’ve linked to.
Notice how the object count doesn’t go down (significantly) between GC
runs:
5173 objects, 0.056349 GC time, 5169 remain
I think it’s taking 56ms to loop through all GObjects and their
properties (allocating and deallocating lots of memory along the way).
When I showed a GTK+ hacker the Ruby-GNOME GC method he said “that’s a
terrible way to do it” and “GTK+ was never designed to be used that
way.”