Hmmm . . . does this present a problem from your point of view? I agree with you in that it's a bit of a puzzle, but perhaps FM doesn't need more than one processor (core). Although I've had occasion to check core usage with more CPU intense programs I've never thought to check FMPA usage. I've always assumed it would be very minimal and I think I'm correct.
Yes, it is a problem. I have also have a quad-core i7 (MBP) with 8GB RAM and two 6Gb/s SSD's (no spinning disks!). On a relatively simple 2.79M record database (GEDCOM records) then indexing of a field takes a few 10's of seconds -- all a pure CPU activity (as seen by Activity Monitor showing disk activity as nothing and the Dock icon showing 100% of one CPU thread).
Sure, the SSD's make any I/O operation fly, but the advent of devices with the newer 10Gb "Thunderbolt" interface will make I/O even less of a bottleneck than it traditionally has been.
Indexing is a classic operation easily re-coded; it is one of many similar operations which are highly parallizeable (i.e.: can take full-advantage of multi-threading capabilities).
FMP functionality is great; don't let it become an "also-ran" product by hobbling it by staying with a single-threaded implementation of most operations.
Besides indexing, there are other simplistic parallel opportunities among such simple things as giving the display updating separate threads (which would help for those times when one does not want to use "Freeze Window" in order the watch the 'progress' of a script). Four open windows could use at least 4 separate threads, with scripting on another thread (or two), and the "backend" file I/O is still another thread or two (e.g. with indexing and other "auto-calculations") -- that scenario alone could utilize 7-8 threads of processing.
I've done some more testing / evaluation on a quad-core (8 threads - MBP2011) with solid-state disks, and that single-thread is REALLY a limitation.
When running scripts which process a GEDCOM file (genealogy records) into a set of relational tables (e.b. people, events, relationships), the CPU usage is 98-100% -- for one thread only -- and the associated file I/O is write-only (since it is creating new records in those relational tables) ... but ... (and here is the key point) the amount of writing is quite low: less than 900 KB/sec roughly every other second. Since the SSD's support several hundred MB/s I/O, and even rotating disks on this system can do >40MB/s, I/O is clearly not the limiting factor (neither is memory - it has 8GB of RAM and only ~1/3 is used with FMP as the only application running).
Agree Dan well stated, I too have dual quad core and SSD, As soon as the overall CPU hit about 20% everything stops, that is with Filemaker, no problems with Quickbooks. With our data collection portion of the system we really see it. GHM if 2 or more people try to enter data at the same time, then everybody can end up waiting for several minutes. All I can say is: glad I am not the one who recommended Filemaker.
It would be great if this was addressed.
Thank you for your posts and comments.
I recommend that you enter this suggestion into our Feature Requests web form at:
These feature enhancments are captured into a database file that is monitored and read by Development and Product Management where they are then discussed and considered for future releases. There are a couple of questions on this form that only you can answer. Otherwise, I would have copied your posts and pasted them into the web form.