Unstored calculation update on demand. Stored calculations update when a referenced field changes value.
Conditional Formatting/Hide Object When expressions update continually.
How much time a given calculation takes to evaluate is a function of many different variables, but those that compute an aggregate value-a value from a set of records--such as a summary field or the Sum() function will take much more time than those that do not compute such a value. The amount of time it takes for an aggregate value to compute will be a function of the number of records that supply data to that aggregate value. This is why you don't want to show all records on a layout with a summary field or two if you have millions of records in the underlying table.
ExecuteSQL calculations, in my experience, vary a lot in how long it takes them to evaluate since the query expressions I might construct will vary greatly in complexity and in the number of records in the tables the expression queries. If I recall the details correctly, this SQL has be be run by FileMaker through an interpreter to in order to execute the query, which requires even more processor cycles to evaluate. And the SQL expression might even include aggregate functions as well to further add to the "computation load" of a given layout that displays data from such a calculation field.
So your worse case scenario might be a conditional format expression that uses a sum function inside an ExecuteSQL query with Joins to several multi-million record tables and a complex multiple term WHERE clause....
Ultimately, you may have to test your layouts with realistically scaled sets of records and be prepared to remove different layout elements during testing to see how much such a change affects how your layout updates.