Re: [ruby-gnome2-devel-en] help with liststore

[hendra k. <pen...@gm...>]

On Tue, Mar 29, 2011 at 10:23 AM, Mike Charlton <mik...@gm...> wrote:

> On 29 March 2011 00:46, hendra kusuma <pen...@gm...> wrote:
> > I use gtk liststore, append and set_value each data
> > but it runs very slow, and I mean Very Very Slow
>
> Yes, creating the list store is very, very slow.  I haven't
> found a better way to do it unfortunately (although for my
> app large lists are rare, so I haven't looked into it fully).
> I'll give you a few general pointers on optimizing ruby-gtk
> apps, though.
>
> Generally speaking, you should avoid creating objects.  1.9.x
> may be better in this respect, but at least with 1.8.x I have
> found that simply making objects is a bottle neck.
> Each object has an overhead (800 bytes???  I can't remember)
> and the amount of memory it takes is huge.  Once you get
> up in the 100,000 object range managing the memory and
> garbage collection can eat CPU on smaller machines.
>
> With large datasets as much as possible I try to use
> arrays of strings (overhead of a string seems to be less
> than a usual object) and then parse the string when I need
> to use it.  So instead of having an array of objects each with
> their field as your liststore, you can have an array of strings,
> parse it when you are creating the fields you want to
> display and again when you select an object.  It seems
> like it would be slower, but it has given me some improvement
> on my app.
>
> The other thing you should do is avoid things like each().
> For whatever reason, each() is very slow in Ruby.  As
> much as possible try to use methods where the loop
> is written in C code rather than Ruby code.  For example,
> try to use collect() with a block.  Things like any?() and
> all?() are significantly faster than setting up your own loop.
>
> Anyway, the best thing to do is to profile your app
> and check what is actually eating the time.  Think of
> different ways to do the same thing.  Various ruby calls
> have very different performance characteristics, so
> keep trying to do things in different ways to see which
> one is faster.  (This is of course after you make sure that
> your algorithms are computationally as simple as possible).
>
>        Hope that helps,
>              MikeC
>

Very helpful
not that I find a solution, but at least I know the problem.
from what I found, what slowing down is ruby, not gtk lib
I guess I need to throw some trial and error a little bit

btw, I have zero knowledge of C.

-- 
Suka linux?
Kunjungi blog saya http://penguinroad.blogspot.com