Re: I found the bottleneck, please tell me how to fix it...

[Maurizio Colucci <seguso forever tin it>]

On Thursday 15 January 2004 08:00 am, Gus Koppel wrote:


Gus,

Thank you so much. I understand I have not been clear at all.

I have been mixing the terms "selection/deselection" and "hiding"
because in my application they are almost the same thing: each time
you select an item, MANY other items are hidden. This is called
narrowing an is the most important feature in my app. Sorry if this
seemed silly.

What I really need is a way to hide an item in nearly constant time
(see further).

> > 1) I need a list widget capable of hiding and showing items in
> >    constant time. I don't see why GtkTreeViews should fulfill this
> >    requirement, since it uses a list internally. (But I need to test
> >    it.)
>
> If you don't want your list of items being stored in a list then you
> can't use VBoxes either. Guess what they use internally?
>
> What do you mean by "constant time"? Periodically? 

No, sorry. I mean, as you later assumed, a time that does not depend
on the number of items. :-) technically referred to as O(1).

> A strict constant
> time to add / remove / show / hide items in a listbox(-like) widget
> (tree) can never be achieved as you likely know. The number of entries
> in the list / being shown always has at least a minor impact on the
> timing of display operations, no matter whether you use a standard
> GtkTreeView or your own HBox-based construct. 

Yes, that is why I said that it would be acceptable O(N), i.e. hiding
an item in a time that only depends on the ACTUALLY VISIBLE
items. These are NOT the items for whic is_visible() returns true!
is_visible() returns true for 2000 items, but there are only about 10
items not clipped away, outside the viewport.

> In your case the impact
> seems to be rather major anyway. Also consider that different computers
> have different speeds. So calculating with "constant time" for GUI
> operations isn't a good idea at all.

> >    It would be ok if hiding and removing could take O(N), where N is
> >    the number of items ACTUALLY VISIBLE (i.e. about ten usually), not
> >    the number of items for which is_visible() holds. :-) is_visible()
> >    returns true even if the item is outside of the current viewport.
> >
> >    This would be like achieving constant time, since N is limited:
> >    N<20 at worst.
>
> The size of the total list of entries would always have (at least a
> minor) impact on timing. Calculating with N == <visible items> only
> instead of N == <total number of items oin list> necessarily isn't
> precise.

Yes, but the widget could keep two lists internally: one with the
actually visible items (about 10), one with the current visible items
(about 2000), and it would be solved...

> > 2) I need a precise behavior: when the user clicks a deselected item,
> >    the item must be selected, and other items must be left
> >    untouched. When the user clicks a selected item, the item must be
> >    deselected, and the other ones must be left untouched.
> >
> >    I did some tests and I couldn't reproduce this behavior with
> >    GtkTreeViews. This would be GtkSelectionMode =
> >    GTK_SELECTION_EXTENDED, but it was deprecated and set equal to
> >    GTK_SELECTION_MULTIPLE, which won't do.
>
> Have you tried this?
> http://developer.gnome.org/doc/API/2.0/gtk/GtkTreeSelection.html#gtk-tree-s
> election-set-select-function
>
> Besides, it's not quite clear to me what operation you really intend. At
> 1. you're speaking about hiding, showing and removing items, in 2. you
> speak about selecting and deselecting items. This is not the same.

I know, I seemed to be contradictory. I eaxplained above that hiding
is a consequence of selection/deselection.

>  I
> think only one of these operations should be performed on clicking on an
> item? Anyway, both are possible when using GtkTreeViews.
>
> Anyway, the conclusion remains that if you use thousands of widgets to
> represent a list of items it will always be slower to handle than if you
> use one widget which is capable of managing multiple (thousands of)
> items in a list by itself. Also memory consumption should be much lower
> since each widget certainly implies much more overhead than a list entry
> inside a GtkTreeView.

Please tell me if the solution I proposed (keeping two lists) seems
feasible to you.

Thank you very much


Maurizio