The patch

profiling screenshot

Can you provide a test case where this makes a difference. This will save time on each ArrayList instance, but how many ArrayLists are being created per AMF response? Does your data have a lot of child arrays?

For those that don't have data with a lot of child arrays and are just getting a lot of data items per response, if you can write your data class to implement mx.core.IUID because there is already a unique identifier in the data (customer account #, employee id, etc) that should also save on UID generation per-item. Or you can try lazy generation of the UID in your data item as well.

-Alex

Alex

the arraylist were created by the mapping AMF<->ActionScript classes NOT by the amf deserailization code by itself
So the performance improvements depend on the data

In our case, a cross plateform Air application (desktop, mobile) this patch was a real improvement (20% of the deserialization)
To test it you can do something like
var list:ArrayList;
var start:Number = new Date().time;
var nr:Number = 10000;
for (var i:Number = 0; i < nr; i++)

var end:Number = new Date().time;
Before and after the patch

You should see a difference on desktop, and much more on mobile

see also
http://mail-archives.apache.org/mod_mbox/flex-users/201310.mbox/%3cCALo+euP=wR3At6k5dXGa9MmmwW5=P-vG=ue3qrqpJmCG4qcQNA@mail.gmail.com%3e

I can see how this improves performance at creation time but is it just postponing works that needs to be done later? (not 100% sure on that btw)

It postpones work that may need to be done later. It is worth taking, IMO.

In our applications
For most of the arraylist created during the amf deserialization : the uid will never be used / generated.

Thanks, your suggested patch has been checked in so you should see an improvement if you use the next nightly build.

Checked into develop branch