1 Reply Latest reply on Oct 13, 2011 8:48 AM by TSGal

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



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


      FileMaker Pro


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


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