Opening events takes forever

Hi all,

I have been using FCPX for quite a while now and have always been wondering why it is loading all events in a library when it is opened. This makes starting up FCPX or opening a library a very lengthy process and I fail to see the logic behind it. Opening an event could be done if and when I need it instead of opening everything 'in case you need it' or is there some obscure reason why it is done on forehand ? Is there a setting to prevent this from happening ?

Final Cut libraries are packaged databases, and not being a database 'guy', I don't know if selective loading would be detrimental or not.

There is no way to disable it that I know of, though I haven't found launching FCP or opening a specific library to be a particularly long process. Things generally open for me pretty quickly. There are likely to be time penalties if, say, your libraries are on a local disk and all of your media is on a NAS or some other remote volume.

It was my understanding that FCP actually *doesn't* load all events on launch. When I open a large library it opens the event that contains the projects, but if I later open another event, I get a loading dialog which makes me think it wasn't loaded in initially. I bet joema would have some valuable insight on the inner workings.

FCP 10.6.5 on macOS 13.6 and 12.6.8

Perhaps a bit of a crude way to look at it, but I believe that FCP will open the database for a given Event if that Event is referenced by something open with the FCP UI.

For example, FCP would need to load the database for the Event(s) showing in the Browser, as well as the Event for the Project in the timeline. If the Project in the timeline references media from other Events, those Events would load, as well. So, the state the Library was last in when open may control what Events load when a Library is opened. As Doug mentioned, the availability of any drive used by the Library and the speed of any drive used can affect the loading time of Events.

The Library has its own (smallish) database and each Event has its own database. In a few Libraries I looked at just now, the Events' databases are much larger than the Library database.

And, yeah, no way I know of to control the behavior of FCP wrt this stuff (with a setting)...

I would imagine that using fewer Events may help the performance and UI responsiveness of FCP. This might mean using more of the metadata capabilities of FCP for organizing things. A simple example of this might be to assign a date or location keyword to groups of media, rather than putting them into separate Events. You would then use a Smart Collection in lieu of any additional Event(s).

It would definitely help to know what Dinky's system specs are, and general working environment - primary edit machine, software versions, internal/external drives (HDD/SSD/interface), quantity of plugins generally, etc.

There are things that can slow it down, but those things can often be optimized.

dmetz wrote:

It would definitely help to know what Dinky's system specs are, and general working environment - primary edit machine, software versions, internal/external drives (HDD/SSD/interface), quantity of plugins generally, etc.

There are things that can slow it down, but those things can often be optimized.

Good points, Doug. Offering advice to "FCP is running slow" without sufficient details can be a fool's errand...  My above comments were directed towards possibly obtaining higher efficiency within FCP be reducing the number of Events (and their databases). And, yes, we don't know enough to offer good advice about overall performance and responsiveness regarding Dinky's FCP issue...

Thanks for your reactions, especially thanks to DaveM for the compliment. Regardless of the environment FCPX is running in, my point is it would in all cases be more efficient to open an event if you need it and not 'just in case', From your reactions I take it such a setting does not exist. There may be a good reason for this approach, but it is not really obvious

Dinky wrote:

...Opening an event could be done if and when I need it instead of opening everything 'in case you need it' or is there some obscure reason why it is done on forehand ?...

Every event, every project, and every project snapshot is composed of a separate SQLite database.

There is significant overhead in opening a SQLite database. However, there is also overhead in maintaining that database connection. That overhead may include memory to maintain the database state. E.g,  memory for prepared statements (pre-compiled query), transaction logs, and other bookkeeping data structures. It can also include I/O overhead for the per-database transaction journal. So there is a tradeoff between the overhead of opening the database vs the overhead of keeping them open, which is why they all aren't just left open.

To partially mitigate that overhead, one method is having a pool of open database connections (sort of like a thread pool), and reusing those as needed. It's possible that FCP does that because you usually don't see the "opening..." messages and associated delay, but there's some vaguely defined threshold whereby they appear.

There are a few things that may aggravate this. If you have lots of projects and lots of project snapshots, each of those comprises another database. A compound clip uses inheritance whereby changing the compound clip (held by the event database) will propagate to all references in all timelines (held by the timeline databases). That by itself is not bad.

However -- IF you then create many snapshots of projects that contain compound clips, that severs the parent/child relationship of all compound clips referenced by the timeline, and forces FCP to duplicate lots of data (which would normally be in the project database) in the event-level SQL database. That can cause an immense amount of database I/O.

So there is a non-linear antagonistic relationship between compound clips and project snapshots. DaveM and I investigated one case where the overhead was stupendous -- I think it was 5 million rows in one table of the event database. It would barely run.

Even if not that extreme, it can make opening the event slower because while a given project doesn't need to be open, the event must be open (or kept open) for any possible library-wide query or library-wide smart collection.

The I/O profile of SQLite is dominated by small, random I/Os. Likewise, the I/O profile of FCP building thumbnails and waveforms are small random I/Os. For those reasons, try to use the FCP "lean" library principle. IOW import all media using "leave files in place".  Keep that library on an SSD. If the FCP cache can also be on that same SSD, that's also good. But no existing disk subsystem can compensate for certain extreme edge cases.

You might also consider using keyword collections and keyword ranges as opposed to creating a lot of events in your library. Some types of projects may warrant many events, but even some moderate documentaries can be organized with only a few events and a good variety of keyword collections. As a rough example, try making your library with one single event called "FOOTAGE". Import all your footage from all your cameras into this single event. Once imported, either using "left in place" or " copy to", select all the clips from one camera and create a keyword collection for "Sony a7II". Repeat the process for additional cameras. You can then drill down to create collections with even more specific wording. Maybe this will prove useful to you and this may or may not have some impact on loading time of your library.