I have no idea why you're using unstored calcs that reference that many fields, or why one of your fields has so many repetitions.
Why not start over with what you're trying to do with that table and layout, so we can suggest a proper structure that is optimized for performance.
Right now you are basically increasing the amount of calculations needed to evaluate layout contents exponentially. You could be causing hundreds of thousands of calculations to require evaluation without realizing it.
Get rid of the repeating fields.
Get rid of the unstored calculations.
Get rid of the Conditional Formatting.
Basically, you're giving FileMaker way too much to do when it tries to render. Especially if you have a long dependency tree (one calculation depends on another, which depends on another, etc.). If you're evaluating across a relational join, it can get even worse.
With more detail, we might be able to give you more specific suggestions. But any time you're dealing with large numbers of unstored calculations, you're going to see performance degradation.
the speed enhancement I can think of has already been mentioned - store as many calculations as you can.
Calculations based on other calculations can't be stored until the base calc is also a stored calc, along with other factors (globals, related fields and summary fields); so consider that.
Depending on the size of your tables, you could go the apparently crazy route of substituting static, script-populated fields that can be indexed. You can use these static substitutes to temporarily store summary, related and global data.
Populating these static fields might be something you can do once after midnight, and then use all day.
If it worked, you wouldn't be asking for help ...
You don't say how these unstored calculations are created, but you may be better served with a script that populates variables for use in a Virtual List. Or use David's suggestion of static fields that can be indexed. Either way, it's going to be faster than a pile of unstored calcs (Conditional Formatting) on top of another pile of unstored calcs.
In any event, you can't leave what you have and expect it to perform well. I'm in the middle of a project for a client who did exactly what you did, and she came to me precisely because of the performance issue. The solution had to be refactored to get rid of the unstored calcs and sorted relationships; you can't just band-aid this sort of thing.
If you are performing your calculations in 'List' view you can greatly increase the speed by switching to 'Form' view and freezing the screen prior to executing calculations. After the calculations are complete go back to the 'List' view to display the results.
Your report looks awesome.
Consider the idea of a small "display-only" or "report-only" table that holds a temporary set of data points for your graph. Then see if you can use FM Charting to accomplish (some of) what you're doing. Then you wouldn't have to manage colors, for example.
I don't believe you've mentioned whether this is hosted on your LAN or over a WAN hosted on the Internet?
You've received some good advice above, but I'd like to add an alternative point of view. All software design is a compromise, such as time, features, speed or money and a solution usually has to select from these in terms the objectives and priorities.
We tend to have numbers of complex and large systems, which require all the features that FileMaker provides, including those that should not be used when using the 'thin' development techniques required for speed optimisation over a WAN. We also remain wary of overuse of PSOS due to the lack of debugging tools and lack of detailed information on the impact on server resources. We use WebDirect sparingly due to the lack of full functionality, although this is improving with each release.
Therefore, we (and our clients) prioritise speed, reliability and productivity over cost. We do appreciate this is not for everyone.
Therefore all of our CRM solutions are designed for streaming using Citrix or RemoteApp. In this case we are able to deliver all of FileMaker's features over the WAN at speeds that meet (and occasionally exceed) a LAN, despite there being additional cost due to each user having a dedicated license to use these systems.
On the plus side, replace field contents on thousands of records that can take half an hour from FileMaker to an Internet hosted FMS server, take less than 60 seconds. Complex reports and layouts refresh immediately. There are hidden benefits and cost savings as all software and updates are managed centrally and any version of FileMaker can run on any version of Mac/Windows (or Linux, Android, etc.).
This isn't a sales pitch, our primary business is offering our own products as SaaS. but an alternative way of thinking and another possible option for you. We, along with others, offer this managed service and AWS offer Remote Desktop solutions. It is very frustrating to have this brilliant FileMaker toolbox to work with, but due to speed constraints, be unable to use many of the tools.
We don't expect our approach to last forever as FileMaker evolves, but for now it allows us complete freedom to build complex applications for industries such as insurance and manufacturing where productivity is a major factor.
First off, beautiful layout work. It's clear you've put a lot of thought and work into it.
This may have been suggested elsewhere here, but may I suggest that you explore a WebViewer-based display using a library like FullCalendar or DayPilot?
I have tried to build native calendar/scheduling layouts much like yours and I've run into the same trouble, especially when you start incorporating things like conditional formatting and such. Recently I've played with FullCalendar and I'm able to get beautiful results with greater speed and responsiveness.
Both libraries mentioned have free trials, by the way.
I hope this helps.
Thank you for all of the suggestions. I cut down load time from 1 min to 4.5 sec. by creating static fields populated thru script in the start and end date fields pulling from the unstored calc field.
The only caveat is when a phase's date changes, the script will run to update the static fields.
Since this is an infrequent occurrence, it is not a big deal.