Re: FCPX developers, please optimize disk access

[Ladislav Zamba] "As old SQL database developer I'm aware of not optimal programming. For example not optimal SELECTs work fine with small databases on speed hardware, but with thousands of gigabytes of data such SELECTs are weak. And if thousands of users run such SELECTs at same time, servers are in trouble then."

As a SQL developer you must also know that the most effective way to accelerate a database is to give it lower latency storage to operate on. Depending on the size of the database, that is often a matter of loading the entire thing into RAM. Moore's Law and Brute force have been the saving grace of accelerating large databases for a long time, and the same is true for a 64-bit, hardware-optimized NLE.

[Ladislav Zamba] "My USB2 experience tells me that something can be made better."

My USB2 experience tells me that it is some of the slowest, highest-latency storage you can get short of trying to edit over 100BASE-T.

[Ladislav Zamba] "Do you remember problem with doubling project file size when compound clip was made? Apple fixed it. So, I believe that FCPX developers can avoid some unnecessary disk activity and make editing on slow drives and machines faster."

Maybe they could if you had a huge glut of RAM they could load more of the utilized source media into, since they have to store the timeline media somewhere if it isn't going to be read from disk when called upon. However, for a large project, this too is untenable. Think about how much RAM you have, and then how much media you are using in your large project's timeline. I can't imagine what they could do to achieve what you are describing. Sometimes you just need better hardware.

That said, I do agree they need to optimize how FCPX assets are stored- specifically, allowing for separation of Render media from the Project database storage. The Events and Projects databases will be much happier on SSD, while the media can tolerate higher density, lower cost HDD arrays that are built for streaming media and not so good with the IOPS.

Best,
Andy