After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 571596 - GTK_MODULES=gail:atk-bridge slows down incredibly TreeStore in pygtk
GTK_MODULES=gail:atk-bridge slows down incredibly TreeStore in pygtk
Status: RESOLVED DUPLICATE of bug 577098
Product: atk
Classification: Platform
Component: gail
Other All
: Normal normal
: ---
Assigned To: Li Yuan
Li Yuan
Depends on:
Reported: 2009-02-13 09:06 UTC by sandro
Modified: 2011-01-20 10:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22

GDB backtrace (1.67 KB, text/plain)
2010-12-08 03:24 UTC, Sašo Živanović

Description sandro 2009-02-13 09:06:42 UTC
Please describe the problem:
After enabling assistive technologies in ubuntu 8.04 and 8.10 an application in PyGTK that uses TreeStore slows down a lot. On 8.04 it was sufficient to unset GTK_MODULES, in 8.10 I needed to unset assistive tecnologies and restart.

I verified that the responsability was of TreeStore ' append' method with prun inside ipython -gthread.

Here is the main part of the report:

ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   332    4.644    0.014    4.648    0.014 {method 'append' of 'gtk.TreeStore' objects}
   495    0.490    0.001    0.490    0.001 {method 'set' of 'gtk.TreeStore' objects}

the same program on a different machine:

ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   495    0.011    0.000    0.011    0.000 {method 'set' of 'gtk.TreeStore' objects}
   332    0.004    0.000    0.007    0.000 {method 'append' of 'gtk.TreeStore' objects}

Steps to reproduce:
I didn't work out a simple case, I started with the demo in sqlkit ( Any demo there uses TreeView /TreeStore and suffers from this bug. 

Actual results:
With assistive technologies enabled each TreeStore 'append' take around 1/5 - 1/10 of a second 

Expected results:

Does this happen every time?
yes on both Ubuntu 8.04 and 8.10

Other information:
Comment 1 Willie Walker 2009-02-13 13:52:00 UTC
Thanks!  Do you have a pointer to the application and a specific use case of the application?  Sometimes the application can be modified to do things more efficiently.  One example for tree views might be to separate the model from the tree view before performing huge operations on it.

For example:

        model = view.get_model()

        <<<perform a bunch of operations on the model>>>


This has been shown to improve things a lot.
Comment 2 Benny Malengier 2009-03-08 17:31:03 UTC
We probably have the same issue in GRAMPS, a GTK python app, see downstream bug:
Comment 3 Sašo Živanović 2010-12-08 03:24:25 UTC
Created attachment 176033 [details]
GDB backtrace
Comment 4 Sašo Živanović 2010-12-08 03:24:55 UTC
Probably my problem is related to this bug as well.

I am developing my own interface for TreeModel (using python->pygtk->gtk.GenericTreeModel) which is supposed to automatically load data as it is accessed (read: the row is expanded) in the TreeView. However, upon calling "row_inserted" method of TreeModel, application loads all the data there is (which takes time, of course).

I have tracked the problem to gail. It seems that gail_tree_view_ref_child is connected to the "row-inserted" signal. gail_tree_view_ref_child calls gail_tree_view_get_n_children, which "gets the total number of rows including those which are collapsed", forcing my application to load all data.

I know next to nothing about how gail works (in particular, I don't know what the references are used for), so I'm not sure if the behaviour of gail_tree_view_ref_child is a feature or a bug.  Reading the code, it seems to me that a (row, column) pair is referenced by a single integer in gail... would it help if the reference system was changed to a (GtkTreePath row, int col) pair? Or, GtkTreeModel provides some help with referencing, maybe that should be used.

I'm attaching a gdb backtrace.
Comment 5 Li Yuan 2011-01-20 10:47:57 UTC

*** This bug has been marked as a duplicate of bug 577098 ***