-
FCPX performance issue – the perils of compound clips
Much more light is now being thrown on the issues surrounding the performance of FCPX – especially in a number of very interesting posts by T. Payton in this forum.
I thought I would try a few tests of my own to see if I could pin down a few more of the concerns that have been nagging at me as I start to do more serious work with FCPX.
Here’s a test that shows the potential dangers of compound clips, as well as what the exponential project size increase associated with splitting a clip on the timeline.
My first test was to make a new event and a new project and import one 1080P clip of about 2 mins. duration and edit that into a matching timeline. (Note that event, media and project were all on the local drive.)
The project filesize began at 401KB. Then I bladed the clip 20 times. By then the project had mushroomed to over 3MB. I tried the same thing with selecting a range and deleting that again 20 times and the result was the same.
This seems to me to be an excessive bloating of the project from a very simple and basic action and is of particular concern for anyone who likes to make selects in the timeline – quite a common and desirable traditional practice.
I then looked at what happened when using compound clips.
I made a new project and started again with the same clip. I made three blade edits, taking the project size from 400KB to 770KB.
I then made the resulting four clips into a compound clip, which I then also bladed three times. This took the project size to 3.6MB.
I then made another compound clip out of the resulting edits and bladed that another three times, taking the project up to 18MB.
I then attempted the same thing a third time and things started to get really slow as the project grew to a massive 90MB. At this point further editing was not a realistic possibility because of how grindingly slowly the project updated the changes to disk.
Granted this is not a typical scenario as few editors will want or need to nest as many compound clips as this, but it does illustrate the exponential growth of the project size when cutting with compound clips and it’s easy to see how it could quickly lead to serious problems.
It should also be noted that having markers inside a compund clip will exacerbate the problems associated with splitting or otherwise editing that compound clip – the filesize grows even quicker in this case. I tried an example with 20 markers on a clip that I then compounded and the filesize grew 25% faster than without.
Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com -
24 Replies
-
Simon, excellent observations. One thing I am wondering about, what is the effect of using a much longer initial clip. Could you do another simple test of blading using a clip that is 20 minutes in duration? Thank you.
Rick Lang
iMac 27” 2.8GHz i7 16GB
-
exactly what I noticed
so how do we do cut across tracks (which arent there)
the wrap in a compound clip, trim and then split apart compound clip which doesnt work properly
I think this must be getting worked out with the new multiclip as its really not worked out at the moment
-
I would imagine this is going to need to get fixed if multicam is going to be feasible at all as I would imagine a multicam situation with compound clips.
I could care less about the size of the project, it’s the performance that’s troublesome.
I am away from an FCPX computer, but what happens with compounds in Events and not projects?
Also, if you quit and reopen does the bloat remain?
-
Interesting question, Rick.
Here’s another test with a clip that’s 34 minutes long.
Editing it into a new project gave a project size of 184KB, which expanded to 635KB after 20 blading actions.
Starting with another new project I added the same clip and made it a compound – the compounding action only took it up to 197KB.
One single blading action took it up to 1.6MB in one single hit.
While blading the compound 20 times resulted in a project size of 16.6MB.
Quitting and relaunching did indeed “flush the undo queue” but not as much as you’d have hoped – the project size only came down to 5.5MB.
These are worrying results and suggest that compound clips do need to be used with some caution.
Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com -
Jeremy
The point about the project size is that it does slows you down quite quickly in this instance – or at least it slows my machine down once you get up around 60MB until you start hitting beachball territory (Mac Pro 2 x 2.26 GHz dual quad core with 8GB RAM, not blazingly powerful I know).
Quitting and relaunching does help to reduce the filesize but not nearly enough – see my latest post in this thread for more details.
Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com -
[Simon Ubsdell] “The point about the project size is that it does slows you down quite quickly in this instance”
I understand that they are related but if a project was 60MB and performing well, it wouldn’t be that big of a deal in my mind.
-
Alas there does not seem to be any simple mathematical formula that explains your two different test results for simple blading. Thanks for all of the detailed information. Since quitting the application only removes a small portion of the bloat, would you consider this a bug and report it to Apple via the feedback mechanism? You have provided Apple enough information to whet their appetite for determining what is happening in their database.
Rick Lang
iMac 27” 2.8GHz i7 16GB
-
Of course the file size itself is largely an irrelevance – the reason I am highlighting it is what it shows about project bloat most especially when editing with compund clips.
Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com -
As you say, it’s hard to see how the sums work out on this – but it’s definitely worrying that quitting and relaunching doesn’t do enough to correct the issue.
Making selects on the timeline is a fundamental component of most of my workflows with advantages that can’t be achieved any other way, so it’s a concern that FCPX doesn’t seem to be well set up to cope with that.
Have indeed submitted feedback to Apple – but I woukld be seriously concerned if they weren’t already aware of this very basic issue!
Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com -
[Simon Ubsdell] “Of course the file size itself is largely an irrelevance – the reason I am highlighting it is what it shows about project bloat most especially when editing with compund clips.”
We are saying the same thing! 🙂
Reply to this Discussion! Login or Sign Up