I have a master table that needs to calculate the total value from many fields in a related, child table. The total must be shown –not necessarily stored– in the master table layout.

I wonder what's the best option:

1. Create a non-stored calculation field in the master table with Sum (child::value) or
2. Just display a child table summary field with the total of child::value

Both options seems to work but I would like to know if there's any difference in performance, is option 2 better than 1?

Depends on your situation and how it’s deployed, how many child records, etc.

Simple enough to try both ways and test performance.  

3.  Script any edit or creation or deletion of a child and set the total value in the parent. 
4. use a on record commit trigger to set the total in the parent. 
 

both are methods to avoid the unstored  value  in the parent. 

It sort of depends what you want to do here.  If simply displaying the child information in a layout or portal is enough and the record count is fairly low (100-500) then using an unstored calculation is probably fine.  As long as record counts stay low and un-stored calculations fairly 'uncomplex' (eg. not calling other unstored calculations) then unstored calcs are the bees knees.

If you're going to be sorting or reporting on the calculated information then it's probably better to do perform an analysis of the use-case to build a basic data model.