10.3 and an inability to use CPU Memory as well as 10.2?

Pulling my hair out today.
It seems that 10.3 is really struggling to process as well on a 16 camera multicam edit.
All files are proxies (from HD originals) and i'm on my 32GB iMac.
Files are on a 4TB G-Drive Thunderbolt. Considering moving them onto my Pegasus 18TB RAID to see if that helps.

Anyone have any ideas?
Thanks
Dean

I don't know what you used to get in 10.2, but 16 angles in a single drive, even in proxy, is a whole LOT. I would not expect any single rotating drive to cope.

I get that, it was coping in 10.2 though. Seems odd. Going to consolidate and try it on my RAID anyway I think.

gloryhornetboi wrote: ...It seems that 10.3 is really struggling to process as well on a 16 camera multicam edit...All files are proxies (from HD originals) and i'm on my 32GB iMac.
Files are on a 4TB G-Drive Thunderbolt. Considering moving them onto my Pegasus 18TB RAID to see if that helps....

When I test upgraded some libraries to 10.3 it invalided the proxy files and I had to rebuild them. Are your proxy files rebuilt under 10.3? If not it might be a good idea to try it.

I experienced slower thumbnail generation due to lower I/O performance on a large library after upgrading to 10.3 but this might not be valid. I did not have time to investigate before rolling back to 10.2.3. In general the performance reports to date for 10.3 are good.

This is a complicated and time-consuming area to test since some of the issues (if present) might be only on upgraded libraries. So it would require doing an array of timed tests on 10.2.3 before the upgrade, then on 10.3 post-upgrade, then reloading the library from scratch on 10.3 and testing yet again. I will eventually do that but I'm on a big project right now and don't have time.

Like lichinho said, 16-way multicam is really challenging. I am surprised it worked very well on a single-spindle drive. The 4TB Thunderbolt G-Drive is pretty fast, but it's only a single drive.

I think the Pegasus RAID array would be a better choice. However in some scenarios even a fast RAID array can get bogged down. This is when the FCPX I/O load becomes lots of small random I/Os, such as when scrolling down in Event Browser of a large library in filmstrip mode. In that case the high sequential read performance of RAID doesn't help much, and if the RAID stripe size is large it may even impede performance.

I don't know the FCPX I/O pattern for 16-way multicam, but it is certainly reading from 16 media files, albeit proxy. The Pegasus subsystem probably does read-ahead and caching so maybe this will help. Some disk subsystems evaluate I/O requests within a certain window and sort them for "elevator seeking", which reduces thrashing from random I/Os. I don't know what the Pegasus does.

I formerly used a Pegasus R4 but now have a 16TB OWC Thunderbay 4 using SoftRAID, and it seems faster, especially on smaller random I/Os.