AnsweredAssumed Answered

FMP 11 Performance far below capability of hardware; only 1 CPU thread used.

Question asked by DanCornett on Aug 24, 2011
Latest reply on Oct 13, 2011 by TSGal

Summary

FMP 11 Performance far below capability of hardware; only 1 CPU thread used.

Product

FileMaker Pro

Version

11 (and lower)

Operating system version

OS/X 10.6.8 (and lower)

Description of the issue

FMP is not taking advantage of multiple CPU threads.  This is especially apparent on systems with SSD's (solid-state disks), but even is apparent on systems with 6Gb/s rotating disks.

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).

See also an earlier similar report: http://forums.filemaker.com/posts/3ec1605bbf#157731

Steps to reproduce the problem

Any system with two or more processors and fast disk I/O subsystems.

Expected result

At least 2 or 3 CPU threads ought to show activity by just separating updating of the UI from the processing of scripts. There are a lot of other common operations which can also make use of parallel threads to increase performance, such as the oft-used sorting of records (either explicit or implicit as defined in relationships and portals).

While I've read reports on Server edition using more than one CPU, even those reports do not indicate the kind of performance improvement which can arise from making FMP multithreaded.

Actual result

One CPU thread goes to 100%; all other threads are idle, even when I/O rates are low (e.g. less than 1MB/s).

Workaround

Put up with performance which is far below what the hardware system is capable of providing.

Outcomes