Comparing serializations, or why Flash Remoting is not as efficient as some would imply

[Updated: Added reference to which classes were being used. The DataContractJsonSerializer is part of the .net 3.5 release.]

There's been a few discussions recently about the cost of using JSON against using Flash Remoting. Its a fact of life to have to discuss those issues when you work with a lot of Adobe people, especially when you're the Microsoft guys.

One of the discussions is around the performance of JSON and Flash Remoting. There is the BlazeBench application that would imply AMF wins hands down in every configuration. BlazeDS is a Java server that Adobe is apparently open-sourcing, but me being an guy, I wanted to see for myself what all this meant.

You see, in terms of architecture, you will always have a service layer, be it in the shape of a REST api, SOAP endpoints or a flash remoting object that pulls DTOs for display by the application. The difference between each of those solutions is going to be in the serialization mechanism you use. So I wrote a small application that compares the time it takes to serialize objects using the following:

I've not done anything special to optimise any scenario and the object graph is the same. I serialize 1,000, 10,000 and 100,000 graphs with each of the serializers, everything is built first before running the test, everything is serialized to a MemoryStream.

This is what i get.


The big surprise for me was the binary serialization using BinaryFormatter, which is nearly as slow as the XmlSerializer.

More important for this study, the serialization cost of the WCF JSON serializer is only 300 milliseconds, for 100,000 objects.

With those results in hand, I will argue that there is no real performance gaps between WCF JSON, Flash AMF and XML DataContracts. Even with the AJAX extensions JSON serializer, the cost of serializing your graph is probably going to be a fraction of the cost of retrieving such an object graph from a database.

If anyone wants the source code, I'll be more than happy to publish it, provided my client allows it.


PowerShell: Opening explorer in the current directory

[Update again]
As a reminder that my readers are usually much more skilled than I am, two anonymous commenter points out the obvious:

ii .


ii $pwd

Never thought of that. It's just beautiful. Thanks! The second commenter has been chatting with me through the messenger control, and points out that Start-Process is only available if you have PowerShell Commnity Extensions... A fact I missed completely. I stand twice corrected.

I've not blogged any PowerShell scripts for a while... I very often navigate around in PowerShell, but sometimes you want to switch to a graphical view. That's exactly what this script does (note it only works on the file system though...)

function Open-Explorer { Start-Process $(get-location) }


Technorati Tags: ,,


Software that sucks #2: How to not write a patch

Most of you have probably already tried using the source server support in vs2008 for the .net framework code ScottGu announced (it was, after all, 8 days ago...) In it, it's recommended to add a hotfix.

When you try installing it, you get an installation failed notification. If you view the report (generated as a local html document with scripts, running from the local drive, and as such with script deactivated by default, stupid thing number 1), you see the following:

Returning IDOK. INSTALLMESSAGE_ERROR [Error [1].An installation package for the product [2] cannot be found. Try the installation again using a valid copy of the installation package '[3]'.: 1706Microsoft Visual Studio 2008 Professional Edition - ENU]

As a guess, the valid copy of the installation package has the same name as the download from MSDN from which my copy of visual studio comes from. A message in the forums confirms the need for the physical media (or iso) to be present.

So there, my second award for software that sucks comes to the hotfix installer. Next time, a review on how badly the Hotmail outlook add-in sucks.