This probably comes down to the underlying dependency tree. How many unstirred calks and summaries does FM have to process to get the final summary on your layout to display?
It simple a sum of the qty from the child in a one to many relationship. Often having less then 10 child records.
The summary field is in the child table but is being displayed on the parent layout. I am trying now testing a calculation in the parent table of a sum or the child record quantities. it seems to b more responsive so far.
Using a summary total in the parent record is faster, as you've noted than using the summary field in the child record.
Use the summary field in the parent rather than the child.
When using the child as a parent table, use its summary field.
Also check all of your calculated fields and ask whether they should be used in a script to set unchanging numbers in fields. A number field will sum faster than a calculated field, that is drilling down through hundreds of records each of which has a calculated field....
If you have one aggregate value per record in your list view, the total number of records in your found set will make a big difference in how fast the values update.
One tactic that can be used at times is to use a script that computes an updated subtotal and stores it in a number field of the parent record with every event in the child table that will change that value. That means adding records, deleting records and editing values in an existing record all need to perform a script that recalculates the total in the related parent record. But if you can pull this off, displaying a list of records with this stored number field will be dramatically faster than any total that has to calculate "on the fly" when you first pull up the record on the layout.