[FX.php List] Showing last related record - sort in FM or just PHP?

[DC]

here's some code that should get you started timing things accurately  
(note - if you are using PHP5 then you don't need the microtime_float 
() function provided here - you should remove or rename it since it  
will cause errors):

<?php
$time_start = microtime_float();
// put the thing you want to time here
// here we just sleep for two seconds
sleep(2);

$time_end = microtime_float();
$time = $time_end - $time_start;

echo $time;

// replicates PHP5 function
function microtime_float() {
    list($usec, $sec) = explode(" ", microtime());
    return ((float)$usec + (float)$sec);
}

?>


On Oct 17, 2006, at 4:41 PM, Joel Shapiro wrote:

> Hi Dan
>
> I'd be happy to do it.  Any good ways to do a real time test   
> (other than counting one one thousand two one thousand... ;) ?
>
> -Joel
>
>
> On Oct 17, 2006, at 1:31 PM, DC wrote:
>
>> hi joel,
>>
>> since you have your testing architecture set up already i'd love  
>> it if you would take your testing one step further and enlighten  
>> us all about this issue since we all seem to be guessing and  
>> thumbnailing it and it would be cool to know exactly what the  
>> tradeoffs are when you give certain jobs to FMP:
>>
>> speed comparison between an unstored calc field that plucks off  
>> the 'last' record from a relationship and sending related records  
>> back through FX.php's XML processing. the test would have to be  
>> made with a range of different related record numbers starting at  
>> 1 related records and maybe going up to 1000.
>>
>> my assumption is that unstored calc field will be slightly slower  
>> when there aren't too many related records, but with many related  
>> records, the overhead of processing them in WPE and XML will start  
>> to get slow.
>>
>> my question is at what number of related records does the XML  
>> processing go slower than the unstored related calc field?
>>
>> thanks!
>> dan
>>
>> On Oct 17, 2006, at 4:22 PM, Joel Shapiro wrote:
>>
>>> Thanks Dale
>>>
>>> I didn't know about end(), so that's great.
>>>
>>> In quick testing on my local development machine (running FMSA as  
>>> well as FMP and everything else), I couldn't see any real time  
>>> difference between FM's sending up to 1000 related records (just  
>>> for testing) sorted vs. unsorted -- for 4 parent records  
>>> returned. I had thought it'd be slower for FM to sort before  
>>> sending, but it seems negligible.  (And I will sort the  
>>> relationship -- or even just the portal(?) -- just to catch any  
>>> out-of-order entries, as Steve warned of.)
>>>
>>> Thanks all!
>>>
>>> -Joel
>>>
>>>
>>> On Oct 16, 2006, at 6:15 PM, Dale Bengston wrote:
>>>
>>>> Hi Joel,
>>>>
>>>> Well, if your relationship is sorted last-to-first, it will be  
>>>> element 0 of the related field array, so you can just reference  
>>>> that explicitly:
>>>>
>>>> 	echo $value['relationship::myField'][0];
>>>>
>>>> If your relationship is not sorted, you can easily find the last  
>>>> element with the PHP end function:
>>>>
>>>> 	echo end($value['relationship::myField']);
>>>>
>>>> I like to use PHP to do as much of the work as possible. No  
>>>> unstored calc fields necessary here.
>>>>
>>>> Dale
>>>>
>>>> On Oct 16, 2006, at 7:31 PM, Joel Shapiro wrote:
>>>>
>>>>> Great.  Thanks Steve!
>>>>>
>>>>> I'll plan on returning all related records (by default) and  
>>>>> then sorting in php to display only the one I want.
>>>>>
>>>>> Best,
>>>>> -Joel
>>>>>
>>>>>
>>>>> On Oct 16, 2006, at 5:16 PM, Steve Winter wrote:
>>>>>
>>>>>> Hi Joel,
>>>>>>
>>>>>>>> my best advice, sort in fmp in the relationship definition.
>>>>>>>
>>>>>>> but if the WPE will spit back *all* related records regardless,
>>>>>>> wouldn't it be faster to have FM return all the data unsorted  
>>>>>>> and do
>>>>>>> the sorting within PHP?
>>>>>>
>>>>>> Probably... if you were actually going to do some form of  
>>>>>> sort, then it
>>>>>> would most likely be quicker to do it in php. If it was a sort  
>>>>>> order
>>>>>> applied to the relationship I don't think it will make any  
>>>>>> difference...
>>>>>>
>>>>>>>>  if you want to get really trick and you are sure you only ever
>>>>>>>> need one (most recent) record you can make a calc field that  
>>>>>>>> just
>>>>>>>> returns the last record. that way PHP doesn't have to  
>>>>>>>> transform a
>>>>>>>> bunch of XML data that you'll never use.
>>>>>>>
>>>>>>> I've heard it's optimal to not have calc fields on the web  
>>>>>>> layout if
>>>>>>> possible (for speed), but do you think that in this case it  
>>>>>>> could
>>>>>>> still be faster than returning all related records?
>>>>>>
>>>>>> Personally I think this would be the slowest option... unstored
>>>>>> calculation  fields are going to be slower for the wpe to  
>>>>>> process than all
>>>>>> of the related records (IMHO)
>>>>>>
>>>>>> Cheers
>>>>>> Steve
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> FX.php_List mailing list
>>>>>> FX.php_List at mail.iviking.org
>>>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>>
>>>>> _______________________________________________
>>>>> FX.php_List mailing list
>>>>> FX.php_List at mail.iviking.org
>>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>
>>>> _______________________________________________
>>>> FX.php_List mailing list
>>>> FX.php_List at mail.iviking.org
>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>
>>> _______________________________________________
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list