Performance of Google’s Protocol Buffers in Flex (redux)

Atry pointed me to latest release (0.8.7) of his protoc-gen-as3 library. I re-ran my tests to see if it brings any performance improvements – and it does!

Deserialization times are very similar to 0.8.4 which I used previously. I would assume any differences are statistical errors.

Deserialization
AMF 3 Protocol Buffers
Class: Small Medium Large Small Medium Large
Average:
(ms)
445.96 962.16 1313.68 326.26 962.00 1435.76
Std dev:
(ms)
25.23 24.35 15.96 4.69 4.38 9.96

Serialization times are greatly reduced – PB library is now 3.5 times faster then before for small messages, over 4 times faster for medium and 4.5 times faster for large. It is still slower then AMF3, but I for most use cases the difference is now negligible.

Serialization
AMF 3 Protocol Buffers
Class: Small Medium Large Small Medium Large
Average:
(ms)
137.68 214.08 317.76 237.84 563.08 814.70
Std dev:
(ms)
13.11 14.88 16.45 11.52 15.83 17.37

Very good news!

Note: Tests were ran on MacBook Pro, 2.26GHz Core 2 Duo, 2GB RAM.

Advertisements
5 comments
  1. andy m said:

    Hi,

    This sounds very interesting – is there any possibility of posting the source of the project so we could see how this actually hooks together. The documentation on the library’s googlecode site is very minimalist (quite understandable as the author’s 1st language is not english).

    Much appreciated

    andym

    • Sure, I will try to do it by the end of the week. If you have any specific questions just ask – I might be able to help, worked with PB & Flex for couple of months.

  2. Amit said:

    I was looking into google protocol buffers and flex and also wondering if you could share your code? We have to transfer alot of data back and forth to the user and it seams google is more open and not flash dependent which is a great plus

    • Sending lots of data with protocol buffers might not be a good idea – evaluate carefully. For example if you plan to send large messages, you might encounter frame freezes (because flash player will be forced to process whole chunk in one frame). Also, if each message can potentially cause expensive UI processing (live updating chart, large data grid, animation) you might observe frame rate drop. Sending AMF messages can sometimes help you reduce these undesired effects.

  3. andy m said:

    I agree. For high-volume messaging, the value that PB brings is doubtful. I’m guessing (only guessing!) you are looking at a ‘streaming data’ problem. If so, and if you’re frustrated by the scalability issues inherent in BlazeDS and its competitors, I’d suggest you could try one of 2 very neat solutions:

    a) Stream your data from a message-broker (I use either HornetQ, ZeroMQ, or..my preferred RabbitMQ (will scale forever and delivers 10K msgs per sec with no tuning!) – then ‘subscribe’ using Websocket, and use an in-page bus e.g. ‘Pagebus’ / ‘OpenAjaxHub’ to deliver those messages to your flex widget. That works really well. If your server is Jetty…even better, but any server will work. If you google HornetQ web socket you’ll see some examples of this – some guy’s even written a cool lib to do all the heavy-lifting for you.

    b) I’m actually using RabbitMQ and I connect to it from Flex, using Stomp….I can stuff binary data into a byte array over this protocol, and get very good results. We’re writing a Flex streaming app that needs to scale into the 100Ks of users…and this combination is working well. I’d recommend it.

    Andy M

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: