Significant performance issues

Mar 15, 2009 at 8:10 PM
I really like the application, so I asked my father-in-law to send me his GEDCOM export.  It consists of 2791 people.  Everything imported correctly, but the performance is so bad that I can hardly interact with the application.

Any recommendations?  Has this ever been tested with a large genealogy?
Developer
Mar 28, 2009 at 8:31 PM
Hmm.  I tried loading a GEDCOM file with over 12000 entries in it.  It took 2 minutes to load and about 7 second to move between people.   I suspect it is the disc writing which takes ages.  For every note in the GEDCOM file, Family.Show creates an rich text file.  Creating ~3000 documents (9500 for my file) takes quite a while.  If your in to coding, I expect if you disabled note imports in the source code, (in GedcomImport.cs) that would speed up the import massively.
Apr 8, 2009 at 9:09 PM
I too had a similar performance experience on  a  GEDCOM import of only 52 entries! 1 CPU maxed out contsantly. I had an earlier version of the GEDCOM with only 36 Entries (same tree) and that worked just fine. I am guessing that one of the new or updated entries had a small note attached. I will download the source and try to debug as soon as I get the chance.
Alternatively I can desensitise the GEDCOM and supply to other developer who may wish to diagnose.

Otherwise an Excellent product !
Feb 19, 2012 at 1:19 AM

In case anyone is trying to play with this app...

I found essentially two primary issues with interactive performance (not load performance).

1. The animations. When you click on a person in the tree, several animations are performed which consume a good part of the 7 seconds mentioned by elyoh. These are most easily disabled by looking for constants named '*Duration' and setting them to zero, e.g. "NodeFadeInDuration" in Diagram.cs.

2. Constantly maintaining the "Family Data" views behind the scenes. The "Family Data" views are accessed when clicking the 'Expand' button over on the right-hand side. The "Family Data" views cannot be seen simultaneously with the chart, yet a lot of work goes on to update the data for those views as the user moves between people. This extra work is most easily disabled by commenting out the 'guts' of the function OnFamilyContentChanged in the file FamilyData.xaml.cs. If you do so, those views don't change: extra work would need to be done to build the views when the 'Expand' button is clicked.

The size of the tree would have a definite impact on interactive performance, mostly due to the second issue.

FYI.

May 23, 2012 at 2:25 PM

In regards to the animations, if the duration is being set to zero, maybe that part of the code needs to be deleted, unless of course it is a configurable user setting.

May 28, 2012 at 10:53 PM
BAbdulBaki wrote:

In regards to the animations, if the duration is being set to zero, maybe that part of the code needs to be deleted, unless of course it is a configurable user setting.

The plan was to make a user configuration setting.