[FX.php List] Unstored calculations not showing

[Joel Shapiro]

Yes, as Chris states, my testing was only on a very simple unstored  
calc: equal to the value of a particular related record via a basic  
parent_ID match-field (sometimes w/ the relationship sorted).  I  
didn't do any testing of more complex unstored calculations or more  
complex relationships (e.g. multi-predicate, greater-than...), so we  
can't really extrapolate my results into performance predictions of  
unstored calcs in general.

If Frank's concern in his initial post relates mainly to similar  
simple calc fields, though, it seems that he shouldn't have to worry  
much about the performance hit.

Best,
-Joel


On Jan 2, 2007, at 2:23 PM, Chris Hansen wrote:

> Hmmm....  One thing is missing here however, comparative  
> performance with NO related data present.  I don't know that this  
> data says that unstored calcs aren't a performance hit, rather, it  
> suggests that they aren't the slowest way to work with related  
> data.  Best,
>
> --Chris Hansen
>   FileMaker 8 Certified Developer
>   FileMaker 7 Certified Developer
>   Creator of FX.php
>   "The best way from FileMaker to the Web."
>   www.iViking.org
>
>
> On Jan 2, 2007, at 3:01 PM, DC wrote:
>
>> Andrew Denman had written:
>>> Frank,
>> SNIP
>>> And a kindly reminder: there is going to be a big performance hit  
>>> when using
>>> unstored calculation fields on the web.
>>
>> Nope. Not true. That is now a verified myth (since October 2006).  
>> Unstored calcs are not the performance problem many of us  
>> suspected. The biggest speed problems can be traced to other  
>> sources - too many fields on a layout,  too many records returned  
>> in a set (no constraints), etc...
>>
>> See this report from Joel Shapiro from October 17th, 2006:
>> ---------------------------------------------------------------
>> As per Dan's request, I've done some testing: comparing times of  
>> FM returning all related records vs. returning only an unstored  
>> calc.  In all my tests, using the calc field produced faster  
>> results -- even when there was just one related record(!)  (this  
>> seems odd, based on others' reports.  see my notes below for  
>> particulars)
>>
>> Goal:  Display field from last of sorted child records
>>
>> R = Sorted relationship, related field on layout, using: end($v 
>> ['REL::field'])
>> C = Calc field* [unstored], no related field(s) on layout
>> * for calc field, I tried both:
>>   = max(REL::numberField) -- unsorted relationship
>>   = REL::textField -- relationship sorted: descending by text field
>>   both had similar results
>>
>> Times are in seconds
>>
>> Find 1 parent record with 1 child record
>> R: 2.37168607
>> C: 2.32556838
>>
>> Find 1 parent record with 20 child records
>> R:  2.37210186
>> C:  2.29863138
>>
>> Find 1 parent record with 200 child records
>> R:  2.80792115
>> C:  2.48299909
>>
>> Find 1 parent record with 800 child records
>> R:  4.33599532
>> C:  2.74986251
>>
>> Find 4 parent records, each with 200 - 800 child records
>> R:  6.63211448
>> C:  3.94424827
>>
>> Notes:
>> - times are averages of 6-10 trials each (& incl. 2 sec sleep)
>> - not optimized (other fields on the layout) but consistent  
>> throughout
>> - single development machine running FMSA, FM, browser
>> - separation model: Web file (no data) and Data file
>> - match fields: kp_ParentID -< kf_ParentID (in Data file for calc,  
>> and in Web file)
>>    (could this have been different if it were a multi-predicate  
>> relationship?)
>>
>> -Joel