On advantages of AMF serialization over other BINARY serializations:
1) integer are compressed (small positive ints can use just one byte). At large, this alone offsets the header stuff.
2) object references, if an object appears more than one time in a graph, then it must be described only once, then it’s referenced. (Strings too!)

On advantages of AMF serialization (and most other “binary” serializations) over “descriptive” serializations:
1) The client can be instructed to deserialize properties without giving them a name. This is possible only when both sides agree on a specific way order to serialize things. In flash there is sort-of alphabetic order.
2) There is space for metadata, allowing for typed arrays, subclass deserialization etc (XML has too, but then you need another piece of data, an XSD, and then synchronize both parts’ classes to the XSD)

@ycneo …client-side ActionScript applications… not really true, AMF3 specification has been opened and it’s applications are traspassing the Actionscript frontier ( see http://github.com/nesium/cocoa-amf, is an example of using AMF in a non Actionscript environment )

On the other hand @ricardo as you may know I’m not a really backend guy, but …When dealing with a high number of of concurrent users, translating on a really high of concurrent AMF requests… Well one of the main advantages of using AMF is the fact that you are recieving actually objects ( this occurs on Java Backends and I think it’s coming on python ), which implies no deserialization on the client side. In addition to this, if we have a Backend which is able to cache the requests, this number of translation should decrease significally

I found this while answering the comments http://www.5etdemi.com/blog/archives/2006/12/clearing-the-fud-on-amfphps-speed-versus-json-and-xml/
is a 2006 post, but I think it’s still good information

“Action Message Format (AMF) is a compact binary format that is used to serialize
ActionScript object graphs.” (http://opensource.adobe.com/wiki/download/attachments/1114283/amf3_spec_05_05_08.pdf)

So they’re thinking in the generic case, as they intend to provide a transfer format between server-side applications and client-side ActionScript applications, putting focus in easy-of-use (and maybe perfomance) in receiving objects in the ActionScript side.

For similar purposes, but with double-blind approach (i mean, any language in both sides), plain formats like JSON and XML are better, since they can be generated an readed without any extra layer to deal with and without data compression/uncompression needed.

So AMF only makes seems to exchange data with ActionScript applications, and is in that context where get the best of itself. No sense to use it in other enviroments.

That said, maybe on bigger requests/responses AMF takes the prize in making the transfer smaller. I noticed that James did is benchmark transferring 5000 objects, knowing that alone, seems like a huge amount of data to be transferred to clients. When dealing with a high number of of concurrent users, translating on a really high of concurrent AMF requests, I would keep the services as simple as possible, delivering the least possible amount of data. This is where I believe the compression doesn’t help much, it will very likely actually make it bigger, processing longer and, as I wrote above, harder (or impossible) to reply from cache previous to decoding.

But then again this all depends on the application we are talking about. I believe that if your application actually needs to transfer that huge amount of data to every single client, then maybe you have other priorities then communication performance. Only taking a wild guess here anyway.

Well AMF really reduces the size of a message notably, may be you should update that

http://www.jamesward.com/census/

James Ward did create this test, seems not be working right know but was a very interesting comparison tool

Great post anyway