Extreme Lag with program

WHY would one still choose to use it?

Because it's not crippling, only really, really annoying. Restarting the app fixes it for a while. Everything else about FCPX is great. Well maybe not the keyframes.

If you did do a clean install and still have basic issues, then it's probably some hardware problem. Could be related to your RAID.

Unlikely. It doesn't do it unless I am in the app for a long time. Length of the project doesn't necessarily seem to be the culprit. Also it's a RAID that Apple directly recommended and sold me. The thing is blisteringly fast. The problem is once you're working with the application for a while it gets weird. Lots of people are reporting this very same issue. Premiere does not do this on the same machine. FCP7 does not do this on the same machine (each using the same RAID). Like I said above, restarting the app fixes the issue for a while on any given timeline. Just concede that it's an issue with the app. Contrary to popular belief here, Apple/FCPX is not flawless. Just because you don't notice the problem does not mean the problem does not exist within the app. The issue exists and it is real.

Reedifer have you checked the status of the directory with Disk Warrior ? Both on external and internal disks.

In my case, I want to stress that 100% of the time, not 99%, 100% of the time sluggishness is related to high memory usage.

This is why restarting FCP fixes the problem for a short amount of time... until the memory pumps back up again.

I posted in another thread about the memory issues.

1. note the memory usage when you first boot up
2. Open FCP and edit something, work the app, work on a project for 30 minutes or so.
3. note the memory usage now.
4. close fcp
5. note the memory usage, is it the same before you opened fcp ??

** In my case, no it is not, it still will remain about 1/4 used.


Memory issues within the app while running it.

1. note the memory usage from a fresh boot
2. open the app and load a project
3. A real project, with multiple 'tracks', filters, clips (just 422 is fine), titles etc..
4. work the project; timeline trimming, timeline copy/paste, add delete clips titles, preview scrub from browser as well, preview scrub from effects window as well, render some areas, use basic filters such as color correction (which is normally used), dissolve trans (trim some transitions) in other words - USE the app.
5. as you are doing #4 above, does the memory release or does it continue to rise, never getting back to the point, or at least close to it, of the memory level when you first opened FCP??

My example earlier in this post of a multicam clip, is much simpler.
The effects browser was not even used or even open.
No titles were used (before a restart was needed)
No transitions etc..
I added all the clips to the timeline at once (it was a multicam clip)
I played the clip, changed angle where needed, doubled checked the point where the angle changed and did a timeline trim if the position of the change was wrong. Started play again, repeat throughout the timeline... that is it.
Memory usage was 3/4 (at least) used up by the time of around 2 hours of editing this one hour timeline.

Memory usage will not rise like this from even the worst HDD or RAID.
Dropped frames, stutter on playback, short beach ball possible during a HDD search are all that you will see as the result of a slow or bad HDD. It will not effect memory usage.

In all my various tests with a bloated OS with a million apps, or a clean new installed FCP on a new yosemite installation, with NO other apps, no plugins, one thing remained the same.

Sluggishness resulted in direct correlation with MEMORY USAGE

When an app does not release memory, this is known as a memory leak.
This happens while within FCP.
But, there is another step here, the memory will also not release 100% when the app is closed as compared to when the app was first opened... If you want the memory to get back to where it was, before the app was first opened you need to reboot.

There is no sluggishness at all if the memory does not rise to a certain level (in my case about 1/3 usage to 1/2 usage).

Memory, is without a doubt, the issue here.
Not a bloated OS, Not HDDs, Not Hardware.

In my case, I want to stress that 100% of the time, not 99%, 100% of the time sluggishness is related to high memory usage.

older versions of FPX on older versions of MacOS indeed had this memory leak - fix was: launch Terminal, type "purge", hit enter, problem solved ... for the next 30min or so ....

What OS and FCPX vers. do you use?

I have 2 OS's that I have been testing this on.
Both are yosemite latest version.
Both are 10.2 fcpx
Both are installed on SSD
One version has plugins and a OS with tons of software.
The other is clean, nothing but 10.2 on that OS

On one of my OS' I have also 10.1.4 installed because of the progressive clip issue in 10.2.
BTW, both apps seem to work fine together. The only issue is when you open either one of them, it will remember the previous libraries from the other version and ask if you want to update it, or tell you it cant open it because it was made in a newer version of fcp., just click cancel or whatever and you are fine to go.

For the terminal command, is typing 'purge' it?
Do you need to be within a specific directory, etc..?
Do you know the exact steps?

One thing I forgot to mention, is I noticed FCP app did not have 'prevent app nap' selected.
Not too sure what this does, but I do have it selected now and I will report if there is any difference in memory usage.

thanks

@dkag7

I submitted this before I saw your last post.....

Is this with 10.2? I don't see it mentioned anywhere what version of FCP X you are using.

I had problems with lag and sluggish behavior on 10.1 that were not there with 10.0. It was not necessarily memory in my case although I'm sure that didn't help the issue. It wasn't bad enough to make me jump ship and it did not effect my ability to meet my deadlines because, in general, the overall editing experience is much faster.

In 10.2 I am seeing better performance overall. I will be wringing it out for real on projects next week.

This is all on a new Mac Pro and it's not a clean install. It's actually transferred from my old iMac using Migration Assistant only because I had to get it done in a hurry. Otherwise I would've done a clean install.

Launch Terminal, purge, done. but, if I'm correct, I'm logged in as 'Admin' (what is not recommended, I know)

No, I'm no Terminal-jockey, found that advice on the net. What I know is, that under Yosemite it asks for a diff. routine, .. google for it... a while ago I had o use it, 'cause:

Since Yosemite and 10.1.x (haven't updated yet, in the mid of a larger project ...) all fine, no slow-downs, I I would notice with my underpowered system, editing 4k on a MacMini ... :lol:

yes 10.2

one OS clean install of OS and 10.2
the other OS is an update of an update of an update.. with a million apps in the OS.

There is no real difference in FCP behavior between the 2 OS's
This is a good thing, as it shows fcp can run fine on a bloated OS

Other than on the new OS, where just 10.2 is installed, I see no difference in performance in older FCPX versions, same sluggishness when memory usage will not release.

OK, Ill check it out..
Also I will look at "I'm logged in as 'Admin' (what is not recommended, I know)"
I never heard this before.. I am always logged in as admin.

it is
sudo purge (enter)
then your password (enter)

for yosemite.

dkag7 wrote: … I am always logged in as admin.

You don't have kids/your kids have no physical access to your working station?

That's a basic security mesurement, a MacOS running with Admin priviledges is an open door for all kind of ... dirt.

btw: you have tried with a different account on your machine? ...

dkag7 wrote: One thing I forgot to mention, is I noticed FCP app did not have 'prevent app nap' selected.
Not too sure what this does, but I do have it selected now and I will report if there is any difference in memory usage.

App nap is supposed to manage performance when multiple apps are running. Most users I believe disable this for FCPX, Motion and Compressor. Here is Apple's description of App Nap: www.apple.com/osx/advanced-technologies/

Also, some users have reported a benefit by using " Memory Clean" which is a small app that when run sits in the menu bar and reports memory usage. It offers a simple purge function. It's free but there is also a small fee to buy the extreme clean version. If you haven't tried it, it might be worth a shot.

You don't have kids/your kids have no physical access to your working station?

Nope, just me and my dogs... they no nothing of the computer other than 'there he goes again swearing at that box thing'

dkag7 wrote: … my dogs... they no nothing of the computer other than 'there he goes again swearing at that box thing'

yeah, dogs are great philosophers - a wise statement. Esp. the phrase 'box thingie' ... puts every thing into perspective......

My son is more "just wanna show you something!" - and the next 2h he spends at MY computer, or, option #2, I spend 2h to fix it .....

back2topic: have you created for test purposes a New User and observe the same issues.... ?

I did in the past create another user on a different system os..
but honestly I never really knew the purpose of this or what it actually accomplishes.

Not too sure if it would help a memory issue

dkag7 wrote: … never really knew the purpose of this or what it actually accomplishes.…

narrowing options … 
new = clean
When the New User has same issues => the app is the culprid
new user = issues gone => app is ok, ... but your set-up is fishy; could be fixed by a 'clean install' whereas 'clean' does NOT mean to stuff an old back-up from a diff. machine onto a brandnew MacPro .....

… 

dkag7 wrote: ...When an app does not release memory, this is known as a memory leak.
This happens while within FCP.

That is correct. A complex process like FCP may contain 50 threads, each referencing hundreds or thousands of data structures, ports, handles, objects, temp files, etc. These are being constantly allocated and deallocated as execution continues. Each of those takes memory. So memory is consumed by almost any internally allocated resource within the process, not just cache, stack or heap. Thus a "memory leak" is not simply failure to free memory, it is failure (over time) to free *any* object, handle or structure. It simply manifests externally as a memory leak.

The ability to peer into the process varies with each OS. Windows has an extremely detailed performance monitor plus many other tools which allows proficient end users to monitor and graph internal process details over time. I'm not familiar with any similarly capable GUI tool for OS X, but Activity Monitor can show open files and ports for a process.

Difficult cases include asynchronous events and exceptions where the thread suddenly encounters a situation and must release the diverse array of objects, structures, and memory it held. Each code block should contain a "catch" block to release unhandled or unfreed resources. Newer software frameworks may handle some of this for the programmer.

If not implemented correctly, it can cause a "memory leak". These may manifest only under specific circumstances which only partially map to user action. E.g, timing or race conditions can cause it, despite both users doing the same thing. However given enough study, in most cases it's possible to achieve a replication scenario for a given problem site.

It seems unlikely the Terminal purge command would help much. By definition a memory leak is still allocated ("active" in OS X parlance), and purge only releases inactive memory.

The fact that only some people see this doesn't mean something is wrong with their hardware. With a complex program like FCP X, the number of internal states and conditions is gigantic. It's like asking why does a highly-stressed engine with hundreds of moving parts only fail for certain people. There are three ways to resolve this:

(1) Apple software engineers can connect live to a system for remote debugging. I assume that would typically only be done for customers with enterprise-level support. The former Apple Pro Video support is no longer available:

alex4d.com/notes/item/apple-discontinues...are-provideo-support
www.apple.com/support/professional/it-departments/

(2) Apple can provide instructions or tools for taking a memory dump, which is forwarded for analysis.

(3) We in the user community can try to achieve a portable replication scenario. Despite the work involved that is the best way. Live or most-mortem debugging of a malfunctioning process often requires multiple (sometimes many) iterations. Oftentimes when working to narrow down the replication scenario, this will reveal the underlying external cause and provide a procedural workaround. That can be used until the final code fix is done.

I have experienced the slowdown problem myself, it just hasn't been bad enough to warrant dropping everything to pursue.

FYI, I have the MP trash can, Promise P2 RAID, and I have fantastic performance. So it isn't universal, but issues exist.

In response to joema,

1, I have seen memory rise and not release during a preview in the effects browser. I can not remember now for sure but I believe this can be noticed more scrubbing over and previewing a 3rd party plugin that contains any large mov file within the filter/generator etc.. This is 3rd party, but I really dont see how it is a 3rd party problem because the filter is never actually used, you just preview it while scrubbing over it. What were the viewer display settings at that time..? Does it matter?
2. However, in the example I gave in this thread (a multicam clip) the effects browser was never even open. the only common denominator is the viewer display, however now the viewer had the MC viewer open.
3. when I tested editing software at pinnacle, memory leaks were given top priority and were considered 'showstoppers', where the product would not be released until fixed. In my early opinion on this it has to do with either scrubbing/skimmer (I can remember scrubbing bugs in pinnacle products as having memory leaks as well, plus now there is the skimmer to deal with) or the viewer display (possibly settings, what it is playing, size, etc..)

From my tests anyway I can get the memory to rise, and not release, narrowed down to the above steps, though not narrow enough, it is a good starting point. Unfortunately seeing it involves either the viewer or the scrubber, there is no real work around (especially if its something to do with the viewer.)

For those who say they have no problem with this, when you edit (for the most part), do you edit on the timeline (scrub, trim etc.. on the timeline) or do you usually do the trimming in the browser, setting in out points then use any of the insert commands to add a finished clip to the timeline? For myself, 90% of the time, I am timeline editing.

edit: also I want to add, that I usually use the skimmer (almost always) and the setting to view the skimmer clips preview is always on, so I can see clips on a lower track.

A good idea may be to see a comparison of those who have, and dont have this issue.
This issue arises on either short (1 minute) but complex timeline,
A long (1 hour) but simple timeline

For me, one who does have this memory lag issue:

1. Viewer is always set to fit (size)
2. viewer is usually set to better quality
3. skimmer is always on (and audio)
4. skimmer preview is always on
5. show used media is always on (if that is what it is called)
6. I usually edit on the timeline and not in the browser
7. almost always use color correction (mostly just the exposure)


Obviously there are many more that can be added here, but I am trying to just limit these to what I have narrowed down so far as to where the leak may be coming from.

Does anyone who does not see this issue see any glaring differences in how you primarily edit?