Re: gtk performance

[Gergely Polonkai <gergely polonkai eu>]

Hello,

I don’t know about GtkListBox, but when using GtkTree, are you detaching
your model from the treeview while you are doing mass operations on it?

I remember reading it in a tutorial years (decades?) ago that you should
do this.

Sorry, but i have no answers at hand for your other questions.

Best,
Gergely

On Mon, Oct 08, 2018 at 12:24:03PM +0200, ente wrote:
> Hi,
>
> 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.
>
>
> thanx,
>
>
> ente

> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-list


-- 
You must believe in things that are not true.
Otherwise, how will they become?