Flex client/server performance

I had a chance recently to do some Flex-based client/server development work with a small team. During the course of this project questions arose about data transfer using various protocols. Originally the team decided to use a SOAP interface, and this started out fine, but during development someone accidentally requested a deeply-nested graph of objects - and we hit a wall where data retrieval started taking many seconds.

Time for some performance testing, comparing three different protocols:
- SOAP marshaled into ActionScript class-based objects
- RESTful/JSON marshaled into dynamic objects (using as3corlib for JSON decoding)
- RESTful/XML marshaled into the ObjectProxy objects that Flex 3 creates by default

Basic results - the above list shows the performance ranking, SOAP being 3X to 7X slower than the RESTful/XML case.
JSON decoding added approx 20% overhead - presumably because it all happens in AS3 code rather than in native code.

The other thing that stood out - increasing the object graph depth caused an exponential increase in processing time, even though there was only a linear increase in the number of objects in the graph.

Another advantage of the RESTful/XML case is that the ObjectProxy objects created are directly bindable by the Flex UI controls, so if you can live with 'duck-typing' no further marshaling is required.

Later, on a different test setup, the speed of AMF3 was tested, and it was a little faster, with the added advantage (to some) that it was marshaling into class-based objects. (It also handles object graphs better because it uses server-side instance folding). But its a binary format with a limited user base.

Conclusions for now - another strike against SOAP in this environment, RESTful/XML ends up being a pretty compromise in performance and usefulness in the UI.

rgg_20091027_084712

rgg_20091027_084712, originally uploaded by rgordon.

I hadn't emptied out the 'point & shoot' for a couple of weeks, found some pleasant "surprises" in the images. here's a photo of an autumn morning fog bank

20090926-191601-compare-4up

20090926-191601-compare-4up, originally uploaded by rgordon.

i was experimenting with HDR imaging recently, and came up with 4 different renderings of the same image. its clear I need to learn how to control Photomatix Pro! But in the end I was able to get a more interesting and realistic rendering using PSCS4 and the Local Adaptation conversion.

maples on Fort Ward Hill trail

rgg_20090913_151541, originally uploaded by rgordon.

Hiking up Fort Ward Hill trail today, maples lit nicely.

Epson 2200 in Snow Leopard

After upgrading my Leopard system to Snow Leopard, I not only lost the AppleTalk-based connection to my old LaserJet, but also had problems printing to the Epson Stylus Photo 2200. Low-resolution images when printing PDF's from Preview. InDesign refused to recognize any of the custom Epson profiles on my system. When I figured the profiles problem out, it then claimed the printer had the wrong inkset.

Reviewing Apple's support docs, they claim only GutenPrint is supported.

Reviewing Epson's support docs, they claim the older drivers should work fine, but you need to have Rosetta installed in order to instll them.

I never could get GutenPrint's many options lined up to print an accurately color-balanced photo, although I did get closer after a few iterations.

Here's how I got the Epson to work again:

• install the 'latest' Epson drivers and the 'common updater' found for the printer. ( see http://www.epson.com/cgi-bin/Store/support/SupportSnowLeopard.jsp)
• using System Preferences: Print & Fax panel, delete the existing Epson printer defined there.
• in the Print & Fax panel, add a new printer - select the Epson printer (already connected and powered up) and select the Epson driver for it.
• the old color profiles are in /Library/ColorSync/Profiles, yet for some reason InDesign only wants to read them from /Library/Application Support/Adobe/Color/Profiles. One way to fix this is simply to copy the profiles you want into the Adobe folder. (Another way that may work is to put an alias or a symlink to the ColorSync directory. )

I can't wait until I have to try and get the roll paper option working again, that's always a feat with the OSX Epson driver!

rgg_20081130_124908-hdr

rgg_20081130_124908-hdr, originally uploaded by rgordon.

I've been experimenting with HDR photography lately, and one foggy morning I used it to attempt an image I had seen for awhile but had never quite captured - the autumn yellow of the big leaf maple in a conifer forest. This particular morning the fog was just starting to burn through the top of the forest, and gave me enough glow to work with.

Location:
Ted Olson Nature Preserve, Bainbridge Island, WA

JSON support in native code.

I recently needed to look at JSON support libraries for a project I'm working on. It was required that it be a native C or C++ implementation. Some Boost libraries were available. This is a brief report on what I've found so far.

json-c v0.7 (internally its marked as 0.3) was the first one I looked at, mainly because I had used before in an Objective-C environment.

Building it on OSX was easy, creating a libjson.dylib that I could link to. The programming interface is basic C, creating 'json_object's, and adding them to other 'json_object's and 'json_object_array's. There is an incremental tokenizer/parser, as well as the ability to convert a JSON object into a standard JSON string. Its simple, seems lightweight, and I know it works since I've used it before.

TINYJSON-1.3.0 is the next one I examined. This one is heavily dependent upon the Boost C++ Template Libraries, also pulling in the Boost Spirit parser, that I'm unfamiliar with. This was my first attempt at using Boost on OSX, so I first had to pull it down, build and install it, not a big deal. The TinyJSON distribution included a basic set of Boost TEST_CASE's which took me awhile to figure out how ot configure in XCode. Next hurdle is the programming model - its all based on C++ templates, which is useful but sometimes hard to fathom.

Main problem with it though is that its only defined for reading JSON data, not writing it. I need writing.

JSONCPP is the last one I've tried so far. This one looks promising, but I've had problems just getting it to build - it uses something called 'scons' to manage its build process. After following all the instructions, I had no luck. I tried pulling the project tree into XCode and building it manually, and was able to make that work at least. Object structure looks promising, although it has the usual c++ verbosity. Worse though, are no examples and I find that all of the test code is written in Python, and doens't work. i've probably not built something correctly, I just don't know what yet.

A couple of other libaries that I haven't had time to examine closely yet: Jost and Jaula, the former is C++, the latter strictly C. A closer look at Jost is required, as I see it is also Boost-based and it seems relatively simple.

After this little exercise, I'll probably just use the libjson support - its simple and it works. If/when I get more time, I'll look into the C++ versions again.

I was surprised at the dearth of C++ -based versions, I suppose that this is because libjson support is good enough.

9/2009: I ended up doing this for another project too, and again ran into problems with the Boost-based options. Since this was a C++ project I ended up using the Cajun library, and find that it works pretty well. Its a bit stream-oriented but that can probably be changed if it gets in the way too much, or becomes a performance bottleneck. I found it at http://cajun-jsonapi.sourceforge.net/