I am facing performance issues in GTK upon presenting a big amount of
tabular data. First I used GtkListbox for it's layout flexibility.
Handling more than 10,000 items gets inacceptable slow. Switching to
GtkTreeview I can handle some 300,000 items after applying a few
optimizations (column sizing fixed, fixed height mode): a full load
takes about 4 seconds, i.e. the application feels anything but
"responsive" although this is ... ok. Currently I see 2 options:
dropping Gtk in favor of a HTML frontend (that feels awkward to say) or
implementing paging on the GtkTreeview.

At this moment I am analyzing the reasons for the performance issues. I
measured the time it takes to generate a number of labels in a simple
loop (no call ot GtkMain) and to add those labels to a GtkBox:
* 100 labels in 1.7 ms
* 1,000 labels in 20.9 ms
* 10,000 labels in 610 ms
* 100,000 labels in 1m18s
After the loop I pack the GtkBox into a window and show it. That takes
another century to show up. 
If I adjust the loop to skip the packing of the labels into the box,
the times are down to:
* 10,000 labels in 115 ms
* 100,000 labels in 940ms

The windows shows up instantly (although empty of course).

So my performance issue is related to the packing. In my tests with the
GtkTreeview it seems speficially to boil down to the sizing and
signalling of the items: The performance of the treeview was highly
impacted by the fixed height mode & the fixed column sizing (more than
ordering by a column or calling GtkMain while adding rows). So my
question goes down to: How can I further optimize my way of using GTK
in order to speed up UI? Is there any way to add 1,000,000 labels to a
GtkBox in less than a second? Could I somehow suspend the signalling
during UI creation and replace it by a "I am done, now calculate all
the sizes" signal? Am I wrong about my assumption that the sizing
signalling is the cause for the low performance?

With regards to the treeview: After initially creating the data rows I
am calculating values that affect 4 columns out of 10 columns. So far I
determine the GtkTreeIter of the affected row and update all cells in
that row using gtk_list_store_set. Should I adjust to update the
affected columns only? When I implement paging for the TreeView: should
I rather drop the existing ListStore and create a new or is it faster
to overwrite all elements in the Liststore with the new items?

I tried to use the GtkBuilder in order to setup a box with 100,000
labels. This performance was somewhat the same as creating the labels
in a loop (I didn't keep the measurements).

I could isolate the problem to UI rendering. If I don't assign my
ListStore to the Treeview, all is fine. As soon as my ListStore is
filled, I assign the model to the treeview. That's the most time
consuming step.

Last question: is there any way to create callbacks from the javascript
world using the Webkit2Gtk webview? More specificly: I am working in go
language. I am aware of the webview widget. Unfortunately that's a
window. I would prefer to rather place a widget into a native
GtkApplicationWindow. Using Eval I can inject anything into the DOM.
How do I get events from the DOM back to go?

Background on the application:
I am developing a text analysis application. Text fragments get
precalculated attributes assigned. Based on these attributes and the
Levensthein distance between fragments, someone is supposed to (for
now: manually) define text fragment categories (categories). Roughly
speaking the application has a paned window: on the left I show the
category list or an editor for a new / existing category; on the right
I show a list of text fragments with the major 3 attributes or a
details view on a specific fragment: all attributes and a list of
similar fragments.

The smallest amount of text fragments to be analyzed and categorized is
about 300,000 items. The number of items goes easily up to 5,000,000 or
even much more. Categorizing all fragments requires about 100 to at
maximum 1,000 categories, i.e. there is quite some clustering among
those text fragments. On the interface I work with highlight colors: a
human can easily realize which fragements are already clustered and
which aren't. Usually only a small number of text fragment categories
are of special interest. One could compare it to a log file: I don't
care so much about how often someone sucessfully authorized; it is much
more interesting if someone suddenly fails to authorize.


gtk-list mailing list

Reply via email to