On the Ancestry.com blog, Benjamin Nettesheim starts his announcement of
the availability of Service Pack with the remark that Service Pack 3 contains
critical stability and performance enhancements
, and then presents a laundry
list of improvements.
He directs you to a page on the Family Tree Maker site for details. Experience with pages that on that site is that pages which provide accurate product information tend to be removed. The page detailing the defects fixed in Service Pack 1 has been removed. The page detail the defects found in Service Pack 2 has been removed. I will not be surprised if the SP3 page will be removed as soon as SP4 comes out. I saved the page together with the Service Pack itself, for future reference.
The site still does not provide a version history and provides nothing but
the latest Service Pack, so if the latest version accidentally messes up
something that is important to you, you cannot download the previous version
anymore...
None of this creates a professional impression.
The one thing that strikes you about the list of issues addressed in SP3 list
is that is long, despite the fact that is not complete, it lists only some of
the higher priority bugs
, not all.
I browsed through to find some remarkable ones. I had to laugh a bit when I saw
Crash when adding media types .gif and .ICO
, but find the presence of
Problems importing sources from FTM 2005 files
not so funny. These are just
two of the many items that convinced disillusioned users that Ancestry.com did
practically no testing of any kind before releasing FTM2008.
When Ancestry.com (or whatever their current name is) released the Beta,
users complained about thousands of things. Instead of fixing those things,
Ancestry.com hurried to release FTM2008 anyway, and got all the bad press it
deserved. The things fixed in SP1, SP2 and SP3 are really the things that should
have been fixed in response to those Beta complaints. FTM2008 SP3 is what
FTM 2008 should have been - and it still disappoints. Just read over the many
comments left on the Ancestry.com blog to get some idea of remaining issues.
I waited a few days for downloading, but many who downloaded immediately
apparently received a corrupt ZIP file. The ZIP file I downloaded was fine, but
you can downloaded the unzipped patch file now.
FTM2008 was so bad that Ancestry.com hurried to release SP1 (within a month) and SP2 (roughly another month later). Ancestry.com calls these Service Packs, I call them Emergency Patches. Service Pack 3 is the first Service Pack that Ancestry.com took several months to create. I expect that FTM2008 SP3 will soon be regarded as the minimal version of FTM2008, the one you should upgrade to before trying to use it all.
On top of the list is major enhancements to performance
, including file load
time. I decided to test that claim a bit.
I just created the GEDCOM Import Speed
overview. It includes results for FTM 2008 Beta, but only for the 1 MB
GEDCOM. Results for FTM 2008 proper are still missing. I decided to do both the
1 MB GEDCOM and the 100k INDI GEDCOM import test with both FTM 2008 and FTM 2008
SP3.
Now, file load times probably refers to loading of FTM files, not necessarily to
GEDCOM files, but I can measure both to see which times have improved and by how
much.
I start by removing FTM2008 and reinstalling the release version (17.0.0.416), I then run both test, install SP3, and run them again. Simple, but time-consuming, as FTM is definitely one of the slow programs.
The simple act of removing FTM2008 seems to much to ask of FTM’s Install
Wizard. It complains the installation is not finished and then exits. Even after
a system reboot, it complains that the installation is not finished. I guess the
FTM 2008 SP3 Release Candidate I have installed is not compatible with the FTM
2008 Install Wizard I installed earlier. I decide to solve this issue by simply
wiping the entire FTM2008 directory. When I start the setup program to install,
it probably finds the registry and gives me a choice between Modify, Repair and
Remove and I decide to remove to make sure all remnants are gone, but then the
program complains the installation source is not available. Sigh. I apparently
have to Repair first, then Remove, and then perform a clean install. When I try
the Repair, it once again complains it cannot find installation file, despite
the fact that I am installing from the same directory as before. I decide
to destroy the Registry entries and the Application Data in my Local Settings.
After all this, Removal still does not work, but this time round, the Install
Wizard complains about missing a directory called FTM 2008 and SP1
. When I
recreate that directory, by copying FTM2008 and SP1 into it, and then run the
setup program from that directory, the removal option finally works.
In summary: FTM2008’s Install Wizard is, ahem, problematic.
Anyway, after that less than enjoyable experience with Ancestry.com’s Install Wizard, I finally manage to perform a clean install without problems. I do not allow FTM to access the Internet; right now, I simply want to use the original version, and not download any patches. FTM2008 puts up an excessively large dialog to report that there was a problem connecting to the registration server.
Importing the 1 MB GEDCOM into a new file takes less than two minutes; 1m50s.
Remarkably, once it is done importing, FTM2008 tries to paint a rosier picture,
by putting up a dialog that claims it took 1 minute and 36,388 seconds.
Apparently, in a bid to make performance seem better than it is, FTM2008 is
keeping some start-up time or a brief very last step (just after Saving the
database...
) out of the total time. That is wrong. I initially guessed
that it might be the Saving the database...
) step itself that was kept out,
but that step takes
about a quarter of an hour for the 100k INDI GEDCOM, and the difference between
FTM’s reported time and the actual time is a mere 20 seconds.
The import time is 1m50s, and that is 44,2 INDI per second and just below 10 KB per second. That is a bit faster than FTM 2008 Beta. The more than ten percent difference is probably attributable to different compile options used for the beta and the release version, not actual improvement of the import code. The import log lists 10 invalid dates, and those complaints seem correct.
Import of the 100k INDI GEDCOM was considerably slower, but that is not all. The Task Manager showed FTM.EXE to be using about 850 MB. In a typical system, with 1 GB of RAM, such careless memory consumption - more than 22 times the size of the file being read! - will cause excessive swapping, probably reduce the system to a trashing state. The numbers are only this moderate because I have I have 2 GB of RAM installed.
Memory usage drops to about 550 MB when the final import step (Saving to
database...
) starts. The progress bar is updated infrequently, and hovers
around 98 %
for many minutes. When FTM displays the Import Complete
dialog
box, 2 hours, 31 minutes and 11 seconds have passed. FTM claims to have done it
in 2:30.50.145. Import speed is a pathetic 11 individuals per second, and below
5 KB per second.
By the way, if you want to time FTM2008 import and compare to the number FTM
claims, be sure to exercise restraint clicking the OK button on that Import
Complete
dialog box. The time is shown there, but it
is not in the import log.
FTM reports 224 errors in the database. That is not correct. It counts tags such as _ITALIC as errors, while these are perfectly legal GEDCOM extensions, and not errors at all. FTM does not complain about all the _UID tags that PAF generates. Many of FTM’s complaints are about dates - FTM is notoriously rigid when it comes to dates, and that is mostly a good thing, but not all dates it rejects are actually invalid.; FTM apparently does not support either the OR or the FROM .. TO construct.
To test the file open claim, I closed the database and timed how long it took to open it again. Opening the file took 27 seconds. Starting FTM2008 (after closing all files!) immediately after closing it took 15 seconds.
| file | 1 MB GEDCOM | 100k INDI GEDCOM |
|---|---|---|
| time | 1m50s | 2h31m11s |
| time in seconds | 110 | 9071 |
| INDI per second | 44,20 | 11,03 |
| bytes per second | 9.599,45 | 4.277.30 |
I applied Service Pack 3 to run the same tests again. Service Pack 3 upgrades FTM to version 17.0.0.965. I experienced no problems applying the Service Pack.
Import of the 1 MB GEDCOM took 1 minutes and 52 seconds, that is just a tad slower than FTM 2008 without service packs. The dialog box look slightly different, and once again claims to have performed the import process in about ten seconds less than it really takes (1:45.284).
On the first try, import of the 100k INDI GEDCOM takes 2:31:36.752 according to FTM itself, and actually about twenty seconds more, 2h31m58s. On the second try, it took 3h13m25s, and FTM claims it took 3h12m02.
The only difference between these two runs is that the first run was done under unusually favourable conditions; right after a disk fragmentation and a clean restart and with nothing but the essentials running. I normally have at least a simple editor and a browser running, and browsers tend to claim a few hundred megabytes of RAM.
I guess that the problem is that FTM is hungry for even more RAM than Task
Manager shows it to be using Any swapping that happened was not noticeable, but
FTM is a Microsoft .NET application, and .NET will perform garbage collection
and memory compaction before it will swap.
Perhaps it was because I merely closed one database before importing the other
one, without exiting FTM. I do not know and I do not care. I performed a
reasonable test in a reasonable way. Ancestry.com itself can perform a series of
controlled test to figure out the details, but I’d suggest a complete redesign
of the GEDCOM import.
However FTM’s memory hunger impacted the results exactly, I am pretty sure that the numbers produced by consecutive tests would be more considerable more consistent if FTM wasn’t so memory-hungry. Meanwhile, whatever programming sloppiness caused the result, the higher number is the more realistic one, so that is the one going into the table.
Opening the file took 40 seconds. Starting FTM2008 (after closing all files!) immediately after closing it took 21 seconds.
I don’t know what Ancestry.com measured to come up with their claim that SP3 includes performance enhancements to file loading, as Ancestry only posted the claim, no details whatsoever, but my experience is that SP3 is noticeably slower instead of faster.
I have some idea where to look for the speed problem. The database files FTM2008 produces after import of the GEDCOM are pretty big. Remarkably, FTM2008 produces a file some 196 MB large while FTM2008 SP3 creates a still considerably file of 169 MB. I immediately wondered about compatibly, but experienced no problems loading the FTM2008 file into FTM2008 SP3. It did take FTM 2008 SP3 more than 2 minutes (2m05s) to load it. FTM 2008 SP3 did not change the size of the file, so if there are any format differences, FTM 2008 SP3 did not convert the file to the newer format.
Despite the introduction of FTM2008, FTM16 is still relevant as the latest and greatest version of the original Family Tree Maker for Windows. Even fans of Family Tree Maker have been calling on users to avoid FTM2008 and use FTM16. So, I did the same tests for FTM16, version 16.0.350 to be precise.
I need to click OK after already starting the import to confirm a few import options, but if I click fast, the import time for the 1 MB GEDCOM is 36 seconds.
For the 100k INDI GEDCOM the second dialog comes 1 minute and 20 seconds into the import process, and I again click OK to accept the default options. Total import time is 25m09s.
The import listing that FTM 16 produces highlights the program’s limitations. It does not just complain about invalid dates and unknown tags, but even truncates person names because FTM consider the names to be too long! Just as unbelievable is the "Line has invalid character(s) for the current character set." error message; the ANSEL GEDCOM file is fine. The real problem is that, although at version 176 already, FTM does not feature proper ANSEL support. The GEDCOM reader also complains that "Tag: CONT, level increased by more than one, line ignored." while the level increase is actually exactly one, just as it should be. It seems that FTM confuses itself when it has some issue with the previous line. FTM16 fails to show any persons until you close the file and open it again.
So far, the import log may sound informative, but it only provides line numbers and error messages, it does not list the GEDCOM line itself. So good luck finding out just what record line 455933 refers to.
Ancestry.com broke the links to the service packs.
The Patch965.exe file seems to be gone,
the new location of the Patch965.zip file was documented in the Family Tree Maker Service Packs article.
The Patch965.exe link has been removed. The Patch965.zip link has been updated.
The results for Family Tree Maker Beta are from An Early Look At FTM 2008 Beta.
| file | 1 MB GEDCOM | 100k INDI GEDCOM |
|---|---|---|
| time | 36s | 25m09s |
| time in seconds | 36 | 1509 |
| INDI per second | 135,06 | 66,31 |
| bytes per second | 29.330,42 | 25.711,99 |
| file | 1 MB GEDCOM | 100k INDI GEDCOM |
|---|---|---|
| time | 2m15s | |
| time in seconds | 135 | |
| INDI per second | 36,01 | |
| bytes per second | 7.821,44 |
| file | 1 MB GEDCOM | 100k INDI GEDCOM |
|---|---|---|
| time | 1m50s | 2h31m11s |
| time in seconds | 110 | 9071 |
| INDI per second | 44,20 | 11,03 |
| bytes per second | 9.599,45 | 4.277.30 |
| file | 1 MB GEDCOM | 100k INDI GEDCOM |
|---|---|---|
| time | 1m52 | 3h13m25s |
| time in seconds | 112 | 11605 |
| INDI per second | 43,41 | 8,62 |
| bytes per second | 9.427,63 | 3.343,33 |
Copyright © Tamura Jones. All Rights reserved.