Why does Flex use a single threaded model?

Question

Over the past few weeks I have been building a prototype application using a Flex front end connected to a J2EE backend using blazeDS.

The prototype is an experiment to learn flex and see what its suitability is for a complex trading application requiring a large number of dynamic updates (i.e > 20 a second) via a pub sub type model.

During some lightweight performance tests it's become apparent that I need to use multiple threads to ensure the UI remains stable when receiving a large number of updates from the server. All was going well until I discovered that flex has a single threaded programming model!

From a quick Google it looks as though there are numerous hacks to implement thread like behavior.

I am sure many people must have been faced with a similar problem. Can people let me know:

• Are there any good threading libs that are well maintained etc
• Do other RIA technologies such as silverlight have the same problems.
• Why did abobe implement a single thread model?
• Are there any other tricks I can use to ensure my UI is stable.

Answer 1

I've seen very intensive trader desktop types of Flex apps which work fine in Flex's single threaded model. The reason is that internally Flex apps use async network IO. So the UI doesn't block when you are making the requests. You might be running into limitations with BlazeDS and should perhaps consider something that uses RTMP (like LCDS). RTMP is a more efficient protocol for streaming large quantities of data to the client. Also there are ways to optimize the client-side event handling and rendering code so that you don't bog down the UI. Christophe Coenraets has a few good demos on doing this kind of thing: http://coenraets.org/blog/?s=trader+desktop

What you are trying to do is certainly possible with Flex and there are people who have successfully done it.

However there is a open feature request for this on bugs.adobe.com: https://bugs.adobe.com/jira/browse/ASL-23

Answer 2

If you're having issues with the stability of your UI it might very well be that you're not making appropriate use of the UIComponent model in Flex. It works based off an invalidation / validation model that allows for updates to be deferred until the UI thread is ready to repaint the screen. There's a great presentation on it here:

http://tv.adobe.com/#vi+f15384v1002

Even if your Flex app still had trouble handling 20-30 UI updates per second after those optimizations, what human can actually make sense out data changing at that rate? I would imagine that refreshing the UI once per second would be adequate as long as the full data set was available for calculations and analytics.

Answer 3

Not sure if you've seen this already, but you can use PixelBender to effectively get a multi-threaded Flash app. See Using Pixel Bender to do heavy lifting calculations, makes Flash Player multi-thread.

Good luck!

Juan

Answer 4

I'm doing something very similar to this and the limitation is not with the single thread, it's really with all the data that's being sent back and trying to update this in real time. The fact is, you dont need real time, or at least you can bend what "real time" really means.

On the server side, instead of pushing the data immediately after a previous push, have it wait for a second and see if more updates come in. If so, you can push that updated data. There's no reason to immediately return "real time" data, if a millisecond later you're going to be returning another update. I hate to say polling is the way to go here, cause it's not, but pseudo-polling or delayed response is the way to go. Thing of it as a train pulling into a station, and just letting on one person. It's a lot more efficient to stop and wait for a bit and let on 50.

Answer 5

To answer your question about Silverlight, it does in fact allow multiple theads.

Answer 6

Why did abobe implement a single thread model?

Adobe didn't. Macromedia did. The single-threaded model is at the very core of the virtual machine. They'd have to write the Actionscript VM from the ground up to introduce a threaded model.

Answer 7

If your UI is locking up during send or receipt of pub/sub messages, it's likely caused by the message (de)/serialization of the data. The trick is to limit payload sizes with no mercy. Do you really need every field in all the objects you just sent?

Similarly, try not to send objects from Client -> Server that you don't need. Often it's more efficient to send just a key that identifies an object, rather than the entire object itself.

Additionally, you can achieve performance improvements by only sending the data objects to the client (and their respective fields) that will be rendered on-screen, and defer the cost of others until they are actually required. (ie., Data pagination)

LCDS provides this out-of-the-box, however, for BlazeDS you can use either dpHibernate or Gilead for this.

(Disclosure: I'm on the dpHibernate team)