Jesse Smith wrote:Yep, I know doing work for our ancestors isn't a waste of time, just the part where you spend time trying to merge duplicats...only to get that error would be.
I know there has been a lot of feedback sent in regarding how slow the system is. They are building a new version of the program to try and resolve the speed problems, you can try using it at
familysearchlabs.org, click on Family Tree and log in with your new FamilySearch user name and password. I have noticed the same slow loading in some of the functions in the newer program. This makes me think the speed problems are in the way they are retrieving the data and how they are storing the data rather than the amount of memory on the servers or how they have designed the pages. I have noticed the same slow retrieval speeds with the FamilySearch certified programs, so it is not in the software design.
It appears that they have designed the system where there is a list of all of the combined records in a main folder then when loading a list of the names they retrieve those records one at a time by searching for each of those records by their ID#. So if that is correct when there are 80 records in a folder they are doing 80 searches to find and load the 80 combined records. So if there are 1000 users each loading a name with 80 combined records in it you have 80,000 searches taking place all at the same time. Imagine taking this public and having 100,000 users at one time.
In my account I have 380 names reserved for ordinances, when Family Tree loads those names, it first loads a list of all the numbers then begins loading each record one at a time. It takes several minutes to search and load the entire list. You have to sit an wait for the list to load before you can do anything else.
Maybe what needs to be done is to add another field to each record to store the combined folder ID# in, then with one search you could pull all 80 records with the same ID#. The records would each retain their own unique ID# but would also have a field to store the folder they have been combined into as well. Another field could also be added to each record to store the ID# of the user who has put that name in their reserved temple list. A query could then be created for combined records sorted by this ID# so all of the records that have been combined into one folder (those with the same ID# in this new field) could all be sorted and stored together, this would allow loading almost instantly instead of taking minutes. Another query could be created sorted by the reserved ID# to speed retrieval of reserved temple names.
It seems to me this would be much faster than loading a list of numbers then searching for each of those records one at a time.
It hasn't reached the official status of version 1.0 as yet. I'm sure they're aware of the problems, especially the response speed. This is the primary reason why the product hasn't been released into the SLC and Idaho areas of the US yet. Because these areas have such a heavy population of LDS that until the NFS system is ready to handle the workload, those areas are not opened up to its use. 