Whole computer slows to crawl while FCPX processes

[Jeremy Garchow]

Do you have all background processes in FCPX Prefs turned off?

[Joe Marler]

BTW build 354449 is just the regular release version of 10.4.7. It can be seen inside version.plist inside Final Cut Pro.app. I am running that on Mojave 10.14.6 on a 10-core Vega 64 iMac Pro, and so far it runs fine. Certain aspects are considerably faster than 10.14.6, esp GPU-related items.

Are you running Chrome? That can negatively impact FCPX behavior, causing extreme slowdowns and crashes.

The Activity Monitor, the parameters “Memory Used”, “Cached Files”, etc are global, not per process. To see how much memory FCPX is using, double click on Final Cut Pro in Activity Monitor. That will show real, virtual, shared and private memory.

Another possibility is you have a plugin which is misbehaving and causing a memory leak.

You mentioned you exported three projects with no problem but the 4th one caused it. What if you duplicate the project, open it, select all timeline clips with CMD+A then strip out all effects by doing Edit>Remove Effects. If you then try to export that project without effects does it work?

[Dave Smith]

To the previous poster… I do not have background render turned off (assumed it was on for good reason)… but in my quick tests turning it off instantly has a positive effect. Will have to toggle that back and forth as I keep working to confirm.

@Joe Marler thanks for the info… didn’t realize this build is thee build. Does this mean there aren’t multiple builds per app version? ie. the next time the build changes we will move up a version to 10.4.8?

Thanks for the Chrome tip; I tossed Chrome after years of usage just one month ago for it being a general resource hog all the way around (plus the privacy problems didn’t help its case).

Re: Activity Monitor… I was aware that the Used, Cache, etc. were global… that’s why I also posted the value in the FCPX Memory column… at +90gb and climbing it seemed out of sorts with the global values. However, I think I now realize that value is referring to total data processed by the app… so +90gb and climbing shouldn’t have made me think it was a problem. That was my misunderstanding. There was never any red or orange in the Memory Pressure readout so I don’t think it was a RAM issue now, but I’ll keep an eye one that.

Your point about the plugins is something I hadn’t looked into. The only plugin I have is the Coremelt Everything Bundle (SliceX/TrackX etc)… they sent me a dropbox link to an unreleased version 507 ‘a’ on Sept. 25, but I see now they have a new version out as of Oct 11. on their website 507 ‘n’…. wow, ‘a’ to ‘n’ sounds like lots of versions in a short time! Anyway, I’ll try this new version too.

Let me see if these few changes make a difference… thanks for all the help!!

[Joe Marler]

[Dave Smith] “… I do not have background render turned off (assumed it was on for good reason)… but in my quick tests turning it off instantly has a positive effect. Will have to toggle that back and forth as I keep working to confirm.”

I suggest you leave it off, delete all cache files, then do a one-time render of the timeline via CMD+A to select, CTRL+R to render. They will gradually become unrendered as you edit. Then (only when needed) you can manually re-render. When background render is enabled, FCPX does not delete the old render files and they can build up, taking space and apparently causing some overhead.

[Dave Smith] …Does this mean there aren’t multiple builds per app version? ie. the next time the build changes we will move up a version to 10.4.8?

Yes in general there are not multiple builds for the same app version, at least once it’s released. If you were a beta tester maybe that’s different.

[Dave Smith] There was never any red or orange in the Memory Pressure readout so I don’t think it was a RAM issue now, but I’ll keep an eye one that.

That is a good thing to check. In general it implies there is no out-of-control memory leak.

[Dave Smith] “…The only plugin I have is the Coremelt Everything Bundle (SliceX/TrackX etc)… they sent me a dropbox link to an unreleased version 507 ‘a’ on Sept. 25, but I see now they have a new version out as of Oct 11. on their website 507 ‘n’…. wow, ‘a’ to ‘n’ sounds like lots of versions in a short time! Anyway, I’ll try this new version too..!”

It is very difficult if not impossible to easily and quickly verify what version of CoreMelt utilities you have. The version number listed within plugin UI can be different from the version number on their download page. Your only recourse is download the latest version. CoreMelt is trying to improve this.

This is a major issue since plugins run within the FCPX process context. Misbehaving plugin code can crash or destabilize FCPX, yet developers do not have the same testing resources Apple has. Ideally plugins should be sandboxed in another process but there are architectural and performance factors which make this difficult.

It is further difficult for developers because there are no Apple standards or UI guidelines for stating version numbers in a plugin. IOW there is no plugin equivalent of Help>About in macOS. In the real world this is significant problem but you don’t see things like this discussed at WWDC or listed on top 50 needed FCPX improvements.