Re: [PATCH] core: Allow grouping all changed medias in "content-changed" signal

["Juan A." Suárez Romero <jasuarez igalia com>]

On Mon, 2011-04-04 at 22:38 +0100, Lionel Landwerlin wrote:
> Let's say you have 8 different views looking at the content being
> changed and suddenly you add 400 files. Then 8 listeners are going to
> process a list of 400 items (o(n)) one way or another, even if they just
> copy the list to process it later. And that might impact the UI
> displaying the results.
> 
> So one way to avoid that could be to pack everything into one object
> which would contain the list of added/modified/removed items. That way
> the UI would still be able to process the items by set of 10 and give
> the hand back to the UI main loop. That object would likely be a gobject
> on which we can apply reference counting, so various listeners still
> parse just allocate an iterator to traverse the notified items.
> 
> The core would be responsible the allocate the objects notifying the
> user, and the plugins would still provide a list of items
> added/modified/removed as in your first patch.


Honestly, I find it quite complicated for a use case that I don't see so
common (having 8 listeners to process a list of 400 items, when most of
plugins are sending just the GrlBox that contains the elements that
changed).

Even in the case of having 8 listeners and a a list of 400 changed
files, you still need to iterate over the list 8 times (as you say,
O(n)). Using refcounting or iterating in packs of 10 elements won't
change the order of algorithm, but it is true that could help the UI to
avoid being stalled while processing all elements.

In that case, I find it more appropriate that UI handles this quite
specific case. You can copy the list in a struct with "refcount" int
parameter and invoke the listeners' method to process the list. The last
listener can free the struct and the list.

Another option could be replacing our GList by a GArray: they have
reference counting. I didn't do it before because I thought GList was
more efficient for this case: you don't need to reserve a chunk of
memory big enough to store all the changed elements.

In any case, you still would need to add code to support the processing
in packs of 10, so I'm not sure if its worth to do it.

	J.A.