Arnie Krauise has done a biting benchmark of FTM 2009 performance. Read the whole thing at "FTM 2009: A Comparison."
Among other performance issues, what really jumped off the page at me was how slow GEDCOM file operations were using the new, 32-bit code versions of Family Tree Maker (FTM). The old FTM 2006/16, the last 16-bit code version of FTM, read a test GEDCOM in 21 minutes. Yes, it was a big file. The new FTM 2008 and 2009 releases, which use the new 32-bit code, took a whoping 342 minutes and 312 minutes, respectively. That's between 5 and 6 hours!
Programmers usually approach file import in straightforword, easy-to-program ways. A GEDCOM file is a text file; open it with Notepad and you can read the contents. It may make little or no sense to you, but you can read it. But I digress. Since it is a text file, the programmers are reading it one line at a time. How can I say so with such confidence? Read my lips: "that's between 5 and 6 hours!"
Read, then process. Read a little more, then process. Read a little, then process. Easy to program; killer on performance. The same sector of data is redundantly read over-and-over from the disk.
Somebody at Ancjestry.com/The Generations Network needs to tell the developers that that kind of inefficient programming isn't going to hack it with consumers. Windows is a modern operating system with features like memory-mapped files. The test system had 2 GB of RAM, if I recall correctly. They could read the entire file into memory in a minute or two, process 100,000+ individuals from the memory buffer in five minutes or so, and be done with the whole thing in under 10 minutes.