Final Cut Pro X: Can You Render Faster?

Posted on by Larry

Recently, David asked:

“When exporting media, would ProRes 422 have a speed advantage over ProRes 422 LT?”

I was fascinated by this question, because I haven’t look at the speed differences between different versions of ProRes before.

However, I need to break this into two parts:


Where possible, I always recommend exporting a master file at the highest quality possible. It is easy to convert a high-quality file into something smaller. It is impossible to convert a small file into high-quality.

The only exception to this rule is when getting a clip posted quickly is more important than quality. In which case, export a compressed file – H.264 or HEVC – and post that. However, as soon as possible after you get your story posted, go back and export a high-quality master file and save that for the future. Just in case…

Even though using a lower quality codec as the final export of a master file doesn’t make sense, there’s still a great deal of value in David’s question!

Since we can change render settings at any time, wouldn’t it be cool if we could choose a codec that renders faster for initial editing, then switch to a high-quality codec just before final output?

So, for this article, I wanted to see what the speed differences were between the different ProRes render options in Apple Final Cut Pro X. And, truthfully, the results surprised me!


I originally planned to compare render speeds between FCP X and Premiere. But, as I got into my tests, I realized that would be like comparing oranges to ducks. They each approach rendering from a different point of view.

There’s no “right” approach – but it is important to know the differences.

NOTE: Here’s an article comparing export speeds using different ProRes codecs in Premiere.


Before we launch into the tests, let’s define a few terms:

By default, render files are stored in the Library, though you can change their storage location using Library > Properties.

NOTE: Here’s a video that explains how.

Faster CPUs and/or multiple cores will render faster. Faster GPUs may render faster, depending upon the codec; ProRes takes advantage of the GPU. However, faster CPUs or GPUs don’t achieve greater quality, just greater speed.


For these tests, I’m using a 2017 27″ iMac. Different computers will render at different speeds, so, in these tests, look at the relationships between render speeds, not the actual speed itself.

All files were stored to the internal SSD, here’s the speed of my storage. (As you’ll discover, rendering does not max out the speed available from the SSD, which means that this storage bandwidth is more than sufficient.)

For a source file, I took one of my recent webinar masters:

To this I applied a single effect: scaling the entire image 50%. This forced FCP X to render the project. All tests were run with the same file, with the same effect. I deleted render files between tests.

NOTE: Applying more, or different, effects will require different render times. Scaling renders reasonably quickly, which is why I picked it.

One last note. Render speeds slow down when FCP X is not the foreground application or when the computer is doing other work. For these tests, I left FCP X as the foreground application and avoided doing other work with the computer. (I, ah, read a book…)

Here are the results:




This computer only had 8 GB of RAM, however during rendering for ALL versions of ProRes, rendering was easily handled within 8 GB of RAM.


The CPU was fully occupied.

You never want the CPU to be 100% occupied, some reserve is necessary to respond to mouse and keyboard actions.


The GPU was fully involved most of the time. Note the fall-off at the end, we’ll talk more about this below.


Final Cut transferred data from storage between 125 – 150 MB/second. Because it needed to process (i.e. calculate) the data in the file, it transfers data more slowly than if it were simply copying the file. In this screen shot, it is reading ProRes 4444 source files and created ProRes 422 LT.


Final Cut supports these codecs for rendering. I thought that the more compressed files – such as ProRes 422 LT – would render more quickly than larger formats.

But, as you can see from my tests, that really isn’t the case. In fact, every time I ran these tests, rendering took a different amount of time! This points out a key fact: render speed is dependent on what else your computer is doing at the time. While I tried to not run any other applications, the computer is ALWAYS doing something in the background.

There really isn’t a whole lot of difference between the three ProRes 422 codecs. The first time I ran this test, they were within eight seconds of each other.

ProRes 4444 takes roughly 17% longer to render than any of the three ProRes 422 codecs, I found this longer time to be consistent between tests.

Another trait I noticed in EVERY test was that as Final Cut got within 85% of completion, it slowed down. Rendering from 45-50% took 20 seconds. Rendering from 95-100% took 45 seconds. You can clearly see the slowdown in the GPU chart above, it started right at 85%. It is also visible in the CPU chart, though I don’t have a screen shot of it.

NOTE: While ProRes 422 LT, 422 and 4444 all slowed at 85%, ProRes 422 HQ consistently slowed at 70%. I don’t know why.

Also, while the three ProRes 422 codecs maxed out the CPU at 95-97%, rendering ProRes 4444 only pushed the CPU to 75% of capacity. Again, I don’t know why.


So, what can we learn from this?

NOTE: To get rid of unneeded render files, select the Project or Event you want to clean up, then choose File > Delete Generated Event Files. Then, choose Delete Render Files. If you delete the wrong files, don’t panic. FCP will simply recreate them.

I found this exercise fascinating, because the results were not what I expected. If you have plenty of storage space, render in whatever codec you prefer. If storage space is tight, render in ProRes 422 or 422 LT.

But, in practical terms, there won’t be any significant difference in speed.

Bookmark the permalink.

11 Responses to Final Cut Pro X: Can You Render Faster?

  1. stu aull says:

    Well. All that work by you for so little diff in results! Sorry and THANK YOU, as always, for another time-consuming Deep Dive Larry.
    And thanks for the additional notes about getting rid of unneeded Render files.
    I have been “manually” cracking open the EDL and digging thru to the High Quality Media and Render folders and deleting there.
    This is esp (your method or mine) valuable if I want to KEEP (and who doesn’t?) the EDL for future client use/revisions without Giga-Quarks of unneeded files…

  2. Mike laib says:

    Hi Larry–
    I’m a musician who uses FCPX (10.4.8) mostly to make music vids, and I would not say I’m super technical, so my work flow intuition may roll a little different from the “norm”. I use an iMac, 6 core, 3.7 Gs, 72 GB memory (10.15.4). With all that, I wouldn’t expect slow rendering every time I edit a timeline clip (e.g. drop in the keyer), yet I usually feel a drag when rendering happens. There is not much else running in the b.g. far as I know. Is there a preference setting or cache setting somewhere that may need expanding, or . . .? Thanks so much for your response. Your videos have been my go-to answers for several years now. Gratefully appreciated. (BTW I work at USC.)

  3. Shaun Budhan says:

    Hey Larry!

    So I remember in the old Final Cut 7 / Compressor days, we had the ability to set up virtual clusters to improve export times.

    My scenario is, editing in Final Cut X 10.4.8 using the latest Mojave.

    I’m exporting ProRes 4444
    The export time is decent on my machine (it’s a 10 Core w/ 128 GB of RAM), but it seems to only use half of my threads. So the CPU usage while using Final Cut X to export ProRes 4444 in Activity Monitor sits close to 50% and peaks at 55%

    Running Compressor 4.4.6
    The export time improved, but only by about 20%. I’d love to saturate all the cores during the export to speed things up.

    Is there a way to set up virtual clusters with the new Compressor to improve on this?
    In Activity Monitor, my CPU usage peaks around 65% using Compressor right now.

    I don’t mind pinning this machine’s CPU to full utilization while it’s running as I usually step away from it while it’s running the job.

    After I’m done with the ProRes export, I use a different encoder to make h264 media for a specific purpose (I can’t use FCPX’s H264 output) I use an old h264 encoder which pins all the threads and almost hits 98% utilization during it’s batch…. so again, I don’t care if Compressor pins the processor in my workflow during the ProRes 4444 export batch.

    Any advice?

    • Larry says:


      ProRes export doesn’t work that way. CPU usage will always be less than 100% due to how FCP X reserves some CPU cycles for other applications and the OS. Export is actually a background process and, as such, can’t saturate your CPU.


      • Shaun Budhan says:

        Well I guess that works for me, at least I gained 20% export time, which will add up, and I can still continue editing in Final Cut.

        I also noticed that H264 encoding exports are drastically improved if I need to do them in Compressor (not typical but nice to know) vs just exporting it in Final Cut X.

        Thanks for the quick reply!

  4. Gini Ignat says:

    Hi, Larry!
    One little thing is puzzling me, if I put the project in, let’s say “Movies” folder on the system drive, ten minutes of 4K material in an FHD timeline renders three times faster vs the same project being on a separate drive, both drives being inside the computer on SATA.

    • Larry says:


      Without seeing your configuration, my GUESS is that the internal drive is an SSD, while the other drive is spinning media. This would account for the speed difference. SSDs are very, very fast!


  5. Jon Dickinson says:

    Why is it always the case that fully rendered clips that only have a Custon Lut applied as an FCPX effect, any this is trur for any such Custom Lut, require re-rendering every time FCPX is reopened?

    • Larry says:


      This is a great question. It isn’t just LUTs it seems to be everything. This is a new-ish behavior and I have no idea why. Renders should remain rendered. And, for some reason, they don’t.


      • Jon Dickinson says:

        Thanks, Larry. It turns out that there are two ways that I have found which don’t result in re rendering. I have tested these two ways applying the identical Lut, and am somewhat bewildered that no re-rendering happens. The first has involved including this Lut as a Custom Camera Lut, but this way, of course, results in the Lut being applied to all instances of the same clip — not an acceptible result. The second way has involved using a third party Lut loader, sold under the commercial name “mLUT”. Strange it seems that these two other application ways, involving the same lut, trigger no re-rendering.

Leave a Reply

Your email address will not be published. Required fields are marked *

Larry Recommends:

FCPX Complete

NEW & Updated!

Edit smarter with Larry’s latest training, all available in our store.

Access over 1,900 on-demand video editing courses. Become a member of our Video Training Library today!


Subscribe to Larry's FREE weekly newsletter and save 10%
on your first purchase.