For Thomas, here is my GEDCOM

Question

Hi Thomas,

Well I got much further. The import resulted in 64,200 nodes and 64,483 edges (I used a larger GEDCOM of over 48,000 people instead of the smaller database export I'd tried before). The UI was extremely sluggish, taking 30 seconds to respond to clicking on a menu or pressing a control-key seqeunce. yEd's working set was 638,816k.  When I tried to save the file, I got an empty exception box (screenie enclosed). It did create an empty output file; the GEDCOM name was 20140125.GED, but the output file it created had the much longer name

201401256314728110736255952.graphml

but it was of zero length.

Thanks for your help so far, I hope you can solve this for me!

GEDCOM file

 

Answer 1

Thank you very much for the GEDCOM data.

With your file I was able to find a minor mistake in our GEDCOM import that results in unnecessary long load times for big GEDCOM data sets. We will improve this for the next version of yEd.

The sluggish UI is mostly due to the amount of time required to render your large graph. Unfortunately, yEd uses a very expensive visualization style for GEDCOM nodes. We probably should add an option to the GEDCOM import settings for choosing between the current visualization style (which is nice for small diagrams) and a simple visualization style that performs much better for large diagrams. I have added a corresponding request for improvement to our internal yEd todo list. For now, I "manually" replaced the expensive style with a much simpler one which improved UI responsiveness considerably.  GraphML archive part1, GraphML archive part2. (There is a 1MB size restrictions for uploads which is why I had to split the rar archive into two parts. On Windows, use copy /b 20140125_graphml.rar.p* 20140125_graphml.rar to merge the parts. On Linux, use cat 20140125_graphml.rar.p* > 20140125_graphml.rar to do the same.)

That said, 64K nodes and 64K edges is HUGE. yEd is not really designed to handle diagrams of that size. Even with the simpler style, the UI will be slow. Moreover, yEd's automatic layout algorithms are not intended for diagrams of that size either. You can try to run yEd's hierarchical layout on your data, but to get a even remotely descent result you will have to let it run for a couple of hours. (You will need to set the "Maximal Duration" in the algorithm settings to something around 99999 to do that.) However, I doubt the diagram will be of much use even after layouting. 2*64K elements is just too much data for a human being to "process".

Finally, if you decide to give the hours-long layout calculation a chance, I strongly recommend using the latest yEd version 3.12 which was released last week. Not only have there been a couple of small performance optimization, we also added the opportunity to preemptively abort layout calculations which might be useful if you change your mind about waiting for several hours.

Comments

Well wow, thanks so much, and glad I could help! Yeah, I knew this had a chance of bringing software to its knees, so to speak. One problem I see in the output, the node names are auto-generated; is it possible to use the same string for the node name as is contained in each node label? It seems NodeXL won't import the node labels. But I'll download the updated executable and see what I can do.