Re: [amfphp] Recordsets

[Jed W. <je...@us...>]

Cool. Now just one other question to throw out there: which is  
slower- the Recordset methods in Flash that I'd use to manipulate the  
recordset, or having amfphp do it? Not that I'm looking for an actual  
answer here, but my point is that I never notice anything from the  
server being slow, but I sure see it in Flash. So I'm inclined to  
keep as much manipulation as possible on the server.

But anyway, the discussion has been helpful- I'll definitely try some  
Recordsets the next chance I get!

Thanks,
-Jed


On Jan 5, 2006, at 11:24 PM, Patrick Mineault wrote:

> Well, when I say it's 80% faster, it's because in the old version  
> what was encoded was just arrays of objects in fact. That's what  
> the adapters did: map a resource to an array of associative arrays.  
> So the "new" amfphp recordsets (they're about a year old now) are  
> about 80% faster than either the old implementation or any aray of  
> associate array (that's with a load of about 10 columns and 100  
> records).
>
> amfphp's bottlenecks are the serializer and deserializer. The  
> serializer's bottleneck is complex nested arrays. Thus using  
> recordsets directly is very advantageous. Sending an array of  
> objects is the absolute slowest thing you can do in amfphp (except  
> receiving an array of objects!).
>
> Patrick
>
> Jed Wood wrote:
>
>> Patrick-
>> Thanks for the response. I do in fact usually do it through SQL  
>> as  you're suggesting, with the exception of those times where I  
>> need to  stuff more than one field into the "data" property.
>>
>> But I think you answered my other question. I wasn't sure if the  
>> 80%  improvement that you've mentioned was compared to older  
>> recordsets,  or compared to other queries in general. If I'm  
>> understanding you  correctly here, using a Recordset would be up  
>> to 80% faster than  sending an array of objects?
>>
>> Thanks,
>> -Jed
>>
>>
>> On Jan 5, 2006, at 2:57 PM, Patrick Mineault wrote:
>>
>>> If you want to use 'data' and 'label' for combo boxes and lists,  
>>> I  highly
>>> recommend that you1 do it through SQL. For example, populating a   
>>> combo box
>>> with names would be done like this:
>>>
>>> SELECT CONCAT(last_name, ', ', first_name) AS label, id_person AS  
>>> data
>>> FROM persons
>>>
>>> Then you can return directly the RecordSet for mysql_queryt and  
>>> set  the
>>> dataProvider directly. Cut the middle man. The advantage: less code,
>>> cleaner, tons faster (up to 80%).
>>>
>>> Look at the documentation for mx.remoting.RecordSet for an idea  
>>> of  all the
>>> good stuff it can do. Filtering, sorting, paging, it really does   
>>> all sorts
>>> of voodoo.
>>>
>>> Patrick
>>>
>>>> This message is mostly for Patrick, but I thought the list might
>>>> benefit from his answer, and perhaps others might have some input.
>>>>
>>>> Many of Patrick's posts over the past year have mentioned  
>>>> Recordsets-
>>>> massive optimizations and such. But I rarely use them. Rather, I  
>>>> run
>>>> almost all my query results through a simple helper function (in  
>>>> PHP)
>>>> that turns them into an associative array before sending to Flash.
>>>> Usually this is done with "data" and "label" properties for easy  
>>>> push
>>>> into ComboBoxes and Lists, though sometimes I just leave it as  
>>>> is for
>>>> DataGrids.
>>>>
>>>> But I feel like I'm probably missing out on some time-saving  
>>>> hassle-
>>>> saving tricks by not using Recordsets, especially if I'm going to
>>>> updating the data I receive.
>>>>
>>>> Thoughts? Opinions? Examples?
>>>>
>>>> Thanks,
>>>> -Jed
>>>>
>>>> p.s.- This question is partially triggered by my experimenting with
>>>> the new CakeAmfPHP build, which I'll be reporting on shortly.
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.net email is sponsored by: Splunk Inc. Do you grep  
>>>> through  log
>>>> files
>>>> for problems?  Stop!  Download the new AJAX search engine that  
>>>> makes
>>>> searching your log files as easy as surfing the  web.  DOWNLOAD   
>>>> SPLUNK!
>>>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>> _______________________________________________
>>>> amfphp-general mailing list
>>>> amf...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/amfphp-general
>>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc. Do you grep  
>>> through  log files
>>> for problems?  Stop!  Download the new AJAX search engine that makes
>>> searching your log files as easy as surfing the  web.  DOWNLOAD   
>>> SPLUNK!
>>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>> _______________________________________________
>>> amfphp-general mailing list
>>> amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amfphp-general
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
>> log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD  
>> SPLUNK!
>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> _______________________________________________
>> amfphp-general mailing list
>> amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amfphp-general
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> amfphp-general mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-general