Speed
FMPerception is very fast under most circumstances, but if you have a very large system (see below for what that means) you may find yourself looking for ways to make it faster still. The first thing to understand is what's different about FMPerception. It takes a very different approach to analysis than the other tools out there. See the section below on that topic. But first, here are a couple of practical things you can do.
Tips For Even More Speed
Choose a Single File
Start by analyzing a single file at a time. If you choose "All Files" on a very large system, you are going to be asking FMPerception to do lots of work that maybe you don't care about. If you can, choose a single file and start there. For example if you are interested in a Field, start with the File that contains the Field, instead of All Files and the Fields.
Use It
FMPerception gets faster the more you use it. As long as you leave the DDR Browser window open, and don't refresh the DDR, FMPerception will have cached the results of all the queries you asked it to perform. So the second time you ask it for the same data, it will be able to instantaneously show you the results.
Partial DDRs
You can also choose to leave parts of the DDR out. Only choose the elements you care about or the files you care about. FMPerception doesn't care, and it may give you enough information to answer the question you are interested in.
FMPerception's Different Approach
FMPerception is optimized for answering questions quickly on fresh data. It can start presenting results in seconds on even the largest systems. It does this by progressively parsing the data as you ask for it. Because it is very fast at opening the DDR and presenting an answer to your question, you can run it very often. You never have to wonder if your analysis is out of date. It's always fresh data. FMPerception can become part of your development flow.
Other analysis tools take a different approach. They calculate the answer to every possible question before they can show you the one single answer you are interested in. Once this analysis is done, you get very quick searches. But because processing the DDR takes so long you can't do it as often, and it requires shifting out of your development mode, and delaying the answers to your questions until later.
Very Large Systems
There is no hard and fast rule on what's a "Very Large System". But anything that contains many hundreds of megabytes of XML data or close to a 100 individual DB files can probably be safely considered "Very Large". Due to the nature of the way FileMaker cross-connects multi-file DDRs, and the technical constraints of the XML processor, the number of files will have an impact on performance before the size of those files.
FMPerception can process very large xml data sets very quickly. However, you may notice that it takes some number of seconds before it can show you the results for any given search. This is because each time you perform a new query, FMPerception does the work of processing the DDR and caching the results.
Other analysis tools may seem faster in this scenario, but only because they have already taken the time to do all the processing. They aren't really faster, they just move all the work of analysis to the front, delaying showing you any results until it's done. Frankly, there is nothing wrong with this approach if you and your development team can accept the constraints it imposes. It's just not the approach FMPerception wants to take.