APPLE FINAL CUT PRO: Apple Final Cut Pro X FCPX Debates FCP Legacy FCP Tutorials

Re: iMac Pro thoughts

COW Forums : Apple Final Cut Pro X Debates

Respond to this post   •   Return to posts index   •   Read entire thread

Joe Marler
Re: iMac Pro thoughts
on Feb 1, 2018 at 5:33:05 pm

[Gabriel Spaulding] "Until recently I also kept all of my media and FCP X Libraries on external 7200rpm RAID drives. With my iMac Pro I keep media on external drives but move the Library (cache files inside) to the internal SSD and now audio waveforms draw significantly faster. Certainly the CPU and GPU play a role in drawing thumbnails and waveforms, but it seems to me that the storage itself makes the most noticeable impact. FCP X generates thumbnails and waveforms for different cameras at different speeds. "

FCPX I/O can be characterized as two very different profiles. One is typical large sequential I/Os for media. This is what benchmarks like Black Magic measure, and spinning RAID arrays are good at delivering that.

The other I/O profile is small random I/Os used for metadata management, in particular thumbnail generation, waveforms, info.plist files, etc. I assume the SQLite calls FCPX makes for database management also generate lots of small random I/Os. Unfortunately RAID arrays are not good at that. SSD drives are better, but even they have limits on random I/O per second (vs MB/sec) rates.

Here is an I/O histogram I generated using the terminal dtrace utility bitesize.d when FCPX was scrolling through a library with AVCHD .MTS files. There are lots of small I/Os:

Which files it does I/O to can be inspected with the dtrace command iosnoop.

Regardless of I/O size or rate, a key item is whether the I/O system is overloaded. This can be examined with the dtrace command iopending which produces a histogram of how many async I/Os are backed up waiting to be serviced.

Using these commands is more difficult than older versions of macOS because of security restrictions. Starting with El Capitan you have to first disable System Integrity Protection. I wouldn't recommend anybody use these unless they are quite familiar with terminal:

How much of what I/O type varies based on what FCPX is doing, and also the codec. Scrolling through a large library with the Event Browser in filmstrip view incurs a lot more small I/Os than in list view. These thumbnails are then cached and subsequent scrolling is a lot faster. However if you resize the thumbnails there's a threshold whereby they must be regenerated. Unfortunately there's no manual control over this, such as in Lightroom where you can say "generate previews" and they are persistent.

As you said there are cases where putting the library and cache files on an SSD (even the system SSD) can help performance. However it can be difficult to determine whether this helps. Just because your spinning RAID array is chugging loudly doesn't mean it's overloaded. Lots of people speculatively put items on SSD, yet it may not help performance if the workflow isn't I/O-limited. If you measure the before/after timing of a specific workload and it's faster with library on an SSD, then that's good evidence but methodically doing such things is time consuming.

I usually use a 4-drive spinning RAID-0 array and often put both library and media there. Sometimes if I have space and it's a "lean" library I'll put it on the system SSD or another external Thunderbolt SSD. If you use RAID-5 there's a write penalty so it might be more important to put scratch/library files elsewhere in that case. However SoftRAID is very good at optimizing writes on RAID-5, so if you use that the penalty is often less than you expect.

Posts IndexRead Thread 

Current Message Thread:

© 2019 All Rights Reserved