Menu
▾
▴
[Gramps-devel] Re : Person & place selectors are horribly slow with large trees.
|
From: jerome <rom...@ya...> - 2017-01-17 12:02:58
|
Paul,
Thank you very much.
In the past, some performances issues have been checked[1] or listed[2]
On my current use, I can get some issues around media handling but
related to my hardware, not to code.
About GEP041[4], it is rather some tests and experimentations, nothing
ready for a Pull Request. I will try to rebase this local branch, but I already
tried to limit display of large items on Selectors. So, maybe these improvements
will not be visible. I did not remember that Nick already made some tests
for filtering data on view... So, I am sure that his code should be proper than
my mix up!
Need to remember, that one main cause of migration, from flat XML to bsddb
as DB backend, was a performance issue. Be able to filter people on Person
selector could be related to large person table, then event selector has been
created, (source, media, place), and notes, etc ... So, number of records
grows with all new major releases. And performance issues sometimes
raised (DB transaction, importation process, batch, tree view, etc ...)
I do not know the complete history of code, but for customization against
standard Gtk TreeView, maybe I did one in the past...
There was a problem for matching items on a large lists like on Selector.
Code was different and based on gtk2. So, I made a feature request[3].
Did not find a nice solution, except a simple addition of _('Last Change')
column ... Today, maybe I will add something like a sort column key, because during
a large edition session we often re-use some recent shared records.
I asked on user mailing for removing this column and maybe provide
most recent used, bookmarked and some recent edited records via
a simple filter, which already exists on Person selector. Users wanted
to keep this column, added some years ago as simple temporary solution
for a real problem... Now, as I understand a little bit more the code,
I thought it was time to close this feature request with a proper solution,
the reason of GEP041[4]! Like for labels on Family Editor,
a work around is never a good solution!
I also thought on a possible improvement on code for large table handling too
when looked at performances with old device. Recent configurations
had problems and was not really able to reproduce it for smaller tables and
old configurations.
Maybe we should try to make a poll, and ask users for testing Nick prototype.
A simple rebase and an archive hosted by github should provide a copy of the prototype?
[1] https://gramps-project.org/wiki/index.php?title=Gramps_Performance
[2] https://gramps-project.org/wiki/index.php?title=Tips_for_large_databases#Flat_views_are_faster_than_Tree_views
[3] https://gramps-project.org/bugs/view.php?id=5024
[4] https://gramps-project.org/wiki/index.php?title=GEPS_041:_New_Selector
[5] https://gramps-project.org/wiki/index.php?title=GEPS_041:_New_Selector#Performances
Jérôme
--------------------------------------------
En date de : Lun 16.1.17, Paul Culley <pau...@gm...> a écrit :
Objet: [Gramps-devel] Person & place selectors are horribly slow with large trees.
À: "Gramps Developers" <gra...@li...>
Date: Lundi 16 janvier 2017, 17h12
Gentlemen;
It seems that in the last few months that there has
been some attempt to make some of the tree selectors open in
the 'fully expanded' mode.
Looking over the bug tracker I note:
Someone did not like that for citations.
Others are (rightly) complaining that performance has
suffered for Person and Place selectors.
While working with progress bars, I assembled a 15000
person, 13000 place, tree and discovered just how awful the
performance is.
My take, opening a tree fully expanded is a
-bad- idea. If a user wants to work with a fully
open tree I would think he should work in a list view
instead. The list view appears to have a lot better
performance in general. Of course we would have to give
the user the option for the selectors, one way or another.
It appears that Jerome and Serge might be thinking
about this already, so I don't want to preempt anything
with a PR as yet.
As an interim step, has anyone considered keeping the
tree view selectors collapsed on open, but using the
Gtk.TreeView.set_hover_expand function? I tried it out and
it seems pretty user friendly, and is easier to use than
clicking the expander icon IMHO.
P.S. I note that our tree model code has a lot of
customization, compared to the standard Gtk TreeModel.
After profiling a bit, I suspect that some or all of that
customization may be contributing to the performance issues,
since it is python code instead of optimized 'C'.
I note that the customization is heading on to 12
years old now, seems to be originally started by Don
Allingham back in 2004.
What is not clear, without a lot more study, is
whether the customization is necessary today, or just there
because historically Gtk did not have functions it does
today.
If anyone has any insight into this, I would be
interested.
Paul Culley
-----La pièce jointe associée suit-----
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's
most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
-----La pièce jointe associée suit-----
_______________________________________________
Gramps-devel mailing list
Gra...@li...
https://lists.sourceforge.net/lists/listinfo/gramps-devel
|