[lmi] Big census [Was: Census-manager Update()]

[Greg Chicares]

On 2014-11-01 23:57Z, Vadim Zeitlin wrote:
> On Sat, 01 Nov 2014 22:05:38 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> For a given column in the census manager, suppose that all cells
> GC> have the same value, except for one differing cell. If we edit
> GC> that differing cell and remove that difference, then all cells
> GC> are now the same, and the column is no longer to be shown. When
> GC> is the display to be thus updated? IOW, when should the function
> GC> that updates the display, CensusView::Update(), be called?
> 
>  I think the best solution for this would involve doing the work done by
> update_class_names() on a separate thread and then requesting that the main
> thread updates the columns only if really necessary -- which should be a
> relatively rare occurrence.

That idea has two parts:

(1) Threads: I'm reluctant to go there at this time, fearing a host
of problems.

(2) Update columns only if necessary: yes, I'd like to do that.

> GC> It is called whenever
> GC>  - a cell is added or deleted; or
> GC>  - a census is pasted; or
> GC>  - any change is made through the tabbed "Edit" dialog.
> GC> But it is not called when a value is changed through direct
> GC> drill-down editing; should it be? I tried this experiment:
> GC> 
> GC> -- 8< --
> GC> Index: census_view.cpp
> GC> ===================================================================
> GC> --- census_view.cpp       (revision 6015)
> GC> +++ census_view.cpp       (working copy)
> GC> @@ -748,6 +748,7 @@
> GC>      Input& model = view_.cell_parms()[row];
> GC>      model.Reconcile();
> GC> 
> GC> +    view_.Update();
> GC>      view_.document().Modify(true);
> GC> 
> GC>      return true;
> GC> -- >8 --
> GC> 
> GC> and concluded that we're better off without that change. It's good
> GC> for a small census, but for a census with 4000 cells it made the GUI
> GC> feel sluggish.
> 
>  I am not even sure how long does update_class_names() really take, but
> just disabling the window and recreating all columns after each change, as
> currently done by Update(), is not going to work well. At the very least,
> i.e. even if we stay with a single threaded solution, both should be done
> only if necessary, not unconditionally.

Yes to everything here.

> GC> (Maybe someday we'll be able to update only the part
> GC> that shows on the screen--like a "virtual" wxGrid, IIRC).
> 
>  This is already the case, wxDataViewCtrl is always "virtual". Just
> redisplaying the data in it with the new columns shouldn't take result in
> any significant delay. But removing all columns and re-adding them might,
> if only because of the UI flicker. I suspect -- and could try it,
> especially if you could share the big test case with me -- that just
> avoiding doing this unless necessary in update_visible_columns() might
> already take care of the sluggishness.

Already "virtual": that's very interesting.

By private email I'll send you a case of similar size that includes
no proprietary or personal information.

> GC> But there has to be a way to trigger Update() aside from the
> GC> triggers documented above, so I asked myself what a reasonably
> GC> ingenious user would try. The answer seemed obvious:
> GC>   http://svn.savannah.nongnu.org/viewvc?view=rev&root=lmi&revision=6016
> 
>  This is indeed ingenious, but I am pretty sure fully automatic solution is
> achievable as well. Definitely so if you're prepared to use a background
> thread and perhaps even without it.
> 
>  Please let me know if it's worth investigating this further,

Yes, please.