RobotLegs Memory Overhead (Low Spec Devices)

StimuliTV's Avatar


18 Apr, 2011 04:54 PM

Hi All,

Just a quickie... Ive been using RL for a while now having 4 large AS3 projects deployed which have all been built on top of the framework and micro-architecture concepts and features. I've built music, video, realtime collaborative and most recently interactive games, all with RL. I'm confortable with RL and have my way of working with it but that doesnt mean i have really gone under the hood much (other than to add some command/event logging).

I still have a lot to learn beyond what i've been doing so far... anyway... I have just started a new job and i'm keen to put forward an argument for using RL as the base for what i'm building. Thing is, it needs to tick a lot of boxes here, most importantly the concept of 'one codebase across multiple devices'... [tada!!!]... We all know Flash/AIR 'should' be able to do it by now but can RL keep up the same promise?

When i mentioned RL during my initial discussions the team were very keen... but there was an argument that perhaps RL has limitations especially with memory overheads on lower spec devices such as STB (set top boxes) and Droidz etc... I'm wondering what the general consensus is in respect of these scenarios... e.g.

Does the potentially recursive nature of introspection and the data used to facilitate injection say make an RL app consume more resources (memory) than perhaps the same app built upon PureMVC? I think this is a recent finding from the devs working on YouView (project Canvas) in the UK, i've heard this as a reason why they've gone for using PureMVC over RL... Any suggestions?

Also there's talk of investigating the The Packager for iPhone... Will a RL app be compatible???


  1. Support Staff 1 Posted by Till Schneidere... on 18 Apr, 2011 06:19 PM

    Till Schneidereit's Avatar

    I have to admit to not having done too much testing regarding the
    memory impact of Robotlegs as a whole.

    One thing I can assert, though, is that Robotlegs (and
    Swiftsuspenders) in itself doesn't create any memory leaks.

    These two things being said, here's some hand-wavy assumptions about
    how much memory Robotlegs *should* be using. The high-level summary is
    that I doubt that Robotlegs uses extraordinarily high amounts of

    Robotlegs has three reasons to use up memory: creating classes to make
    the system work, saving some kind of state in some kind of map or list
    and caching information to speed things up.

    The first of these is shared by all architectures and I don't think
    Robotlegs fares any worse than PureMVC wrt the amount of instances the
    system (or the programmer using it) creates over an application's

    Thus, the saving of state and caching are what's interesting to think
    about (or, much better: measure). The state-saving, again, splits up
    nicely into two sub-categories: Mappings for command and mediator
    mappings held in Dictionaries and injection mappings held in what
    boils down to value objects in Swiftsuspenders. References to the
    latter are again stored in Dictionaries, of course. All of these are
    pretty standard and really shouldn't use much memory at all. Also,
    Other micro-architectures will have to do something similar, with
    similar memory usage, for their operations.

    This leaves us with caching. Essentially, Swiftsuspenders caches the
    relevant pieces of information from the XML returned by
    `describeType`. Specifically, it creates and stores lists of injection
    points and information about the constructor for each class it tries
    to apply DI to. As far as I can tell, it does this in a way that's
    pretty memory-efficient and should therefore not use too much memory
    relative to the amount of classes managed by the system. Note that
    this is only done once for each class, not for each instance.

    In conclusion, I don't see any areas where Robotlegs should use
    considerably more memory than another micro-architecture when being
    used in an application of comparable size and general structure.

    Having now thought about this topic, I think I might actually do some
    measurements and write up my conclusions in a blog post. No promises,

  2. 2 Posted by StimuliTV on 18 Apr, 2011 07:47 PM

    StimuliTV's Avatar

    Hey Till,

    Thank you so much for the feedback. I will put forward your suggestions to the team and also try to make time to run further tests.

    From what i have been told YouView have already done tests (on STBs) but I wasn't so sure they're findings made much sense so im glad i asked, maybe its more personal preference than a decision backed up by hard facts... However we have to listen to what they're saying without making any assumptions. My experience with RL so far hasn't dealt all the device permutations but i did develop an app for PS3 which included Away3D, the main problem here was the rendering and memory used for visual assets, never RL core.

    Do you have any suggestions for the best way of implementing a fair test between the two?


  3. Support Staff 3 Posted by Till Schneidere... on 18 Apr, 2011 08:07 PM

    Till Schneidereit's Avatar

    I'd of course be very interested in seeing the results of any such
    tests. If I were to do them myself, I'd probably set them up along the
    following lines:

    - Create the simplest "hello world"-style app adhering to best
    practices (or my preferred way of doing things) in both frameworks
    - Measure and document memory usage as the baseline-case
    - Add pieces of functionality, carefully making sure that they're
    exactly the same except for differences imposed/ suggested by the
    - Measure and document memory increase for every piece as well as more
    complex combined cases (the latter might not be possible, but I can't
    be sure without measuring ;) )
    - Drill down into the data to see where exactly memory is used
    - Publish the result and notify developers of the compared frameworks about them

    I actually don't think that I'm the right person to do this kind of
    comparison: I hardly know my way around PureMVC at all, so I'd almost
    certainly do a bad job of that version.

  4. 4 Posted by StimuliTV on 18 Apr, 2011 08:19 PM

    StimuliTV's Avatar

    I'll get on this tomorrow and post what i find, nice one!

  5. Support Staff 5 Posted by Till Schneidere... on 18 Apr, 2011 08:20 PM

    Till Schneidereit's Avatar

    Great! I'm very much looking forward to your findings!

  6. 6 Posted by Matt Poole on 19 Apr, 2011 08:43 AM

    Matt Poole's Avatar

    My understanding of this issue would be as follows:

    The theory regarding recurrsion being an issue is that refection in AS3 is limited to the use of describe type which involves recurrsing over all objects in a tree (by reference) and building the XML description. The typical approach for dynamically traversing an XML file would iteself also recurse through all the chidlren to get the class by name (etc)

    Recurrsion itself eats up memory as the call stack is not cleared until all methods in the recurrsion have returned.

    So the question may not be about memory leaks OR total memory used by the framework, but more about the peak memoery used in bootstrapping one or more contexts at startup.

  7. Support Staff 7 Posted by Stray on 19 Apr, 2011 11:27 AM

    Stray's Avatar

    sneaking in a comment from holidays

    On the peak memory issue - there is no requirement to do all your bootstrapping at the outset. You can break up your mappings into commands and do them on a Just-in-time basis.

    Just a thought...


  8. Stray closed this discussion on 19 Apr, 2011 11:27 AM.

  9. Stray re-opened this discussion on 19 Apr, 2011 11:28 AM

  10. Support Staff 8 Posted by Stray on 19 Apr, 2011 11:29 AM

    Stray's Avatar

    Sorry - clicked the wrong button there! Apologies for double posting and closing. Two f-ups for the price of one it seems!

  11. 9 Posted by Paul Robertson on 19 Apr, 2011 04:46 PM

    Paul Robertson's Avatar

    I can't say anything about set-top boxes, but for mobile devices (AIR on
    Android, AIR for iOS) I and my team have been using Robotlegs to build
    several apps for many months, and I've never had any issues caused by
    Robotlegs. There are other bottlenecks in those sorts of apps,
    especially rendering, but we've been completely happy with using
    Robotlegs for these apps.


  12. 10 Posted by StimuliTV on 20 Apr, 2011 10:49 PM

    StimuliTV's Avatar

    Quick update... Investigations have been temporarily sidelined but just as soon as i can i will put something up.

    Paul i agree with you and also Stray as she makes a good point in respect of lazy initialization and on demand creation.

    I think Matt is being cautious about large hierarchical inheritance structures bloating startup in an app... But to be honest my findings with RL have shown for the most part that views, events, models and services are usually pretty light in my apps and they're the elements i tend to inject most. The core architecture makes it easy to decouple these elements (especially as i favor succinct command & mediator to event mappings) so there is less of a requirement to try and wrap all functionality within large hierarchies hence less of a worry with recursion.

    Thanks for sharing guys and girls, you made me think a bit more about the issues so i think the proof of the pudding's in the eating and all that.

  13. 11 Posted by Stray on 22 Apr, 2011 04:54 PM

    Stray's Avatar

    The SS Injector is all lazy instantiation-tastic too. Which also reduces startup loading.

  14. Support Staff 12 Posted by Stray on 11 May, 2011 08:50 AM

    Stray's Avatar

    I'll close this for now - feel free to re-open this one, or start a new thread, when you've got any results - and yes - decoupling FTW!


  15. Stray closed this discussion on 11 May, 2011 08:50 AM.

  16. StimuliTV re-opened this discussion on 16 May, 2011 10:44 AM

  17. 13 Posted by Aaron on 18 May, 2011 02:50 PM

    Aaron's Avatar

    Wow happy I found this post. not having yet talked with the UV team, I was wondering why they had chosen pureMVC over Robotlegs.

    From my understanding RL is lighter than PMVC will be interesting to wee the results of the test, and to see if the UV team are willing to which frameworks. if they have not gone to far already. saying that should be easy to port to RL anyway.

    I have not really bothers with PMVC since the early days of RL and I would like to stick with it. all them Singletons just don't feel write with me.

  18. 14 Posted by StimuliTV on 20 Jun, 2011 07:12 PM

    StimuliTV's Avatar

    Hey all, I've finally managed to build some test apps to compare Robotlegs and PureMVC within an Air wrapper.

    I will post the sources and my findings soon once tested on a few devices. Hopefully i will be able to test a few Android mobiles and tablets, a YouView STB, an Adobe Reference STB and as a standalone Air app.

    As it stands at the moment both apps are nearly identical in terms of code. In my tests so far today Robotlegs seems to be using 1mb more memory than PureMvc once each framework has completed initializing. Profiling should shed some light on this, hopefully its not a SwiftSuspenders issue...

    More to come soon

  19. 15 Posted by Stray on 20 Jun, 2011 07:30 PM

    Stray's Avatar

    Thanks for this - Till and I have been talking about profiling and so on - it'll be great to see how you've done it.

  20. Support Staff 16 Posted by Joel Hooks on 20 Jun, 2011 08:07 PM

    Joel Hooks's Avatar

    I would wager that it is SwiftSuspenders and the caching, but I'd be
    hard pressed to call it an issue. Peak memory usage is what is
    important here and you'd need to get orders of magnitude for it to be
    a serious issue.

    Robotlegs is definitely not lighter than PureMVC in terms of
    performance. It is lighter in terms of boiler plate code, but in the
    frame of this conversation it is "heavier". The issue of performance
    is moot from my standpoint when discussing Flash on mobile as it is
    almost ALL related to the rendering of views which is out of scope for
    both PureMVC and Robotlegs.

    I WOULD avoid mapping complex MXML views using the ViewMap as you
    definitely take a hit there reflecting on view components. The type of
    classes we are typically reflecting on (models, services, mediators,
    commands, etc) are *tiny* in comparison.

    Certainly curious about performance tests. My guess is that PMVC is
    going to come out ahead. It is mechanical and non-magical. In 99% of
    cases it probably doesn't make a difference given a
    micro-architectures job in any application.

  21. 17 Posted by StimuliTV on 21 Jun, 2011 09:23 AM

    StimuliTV's Avatar

    Sorry Joel, bad use of terminology... It was always assumed the caching would be the difference not 'an issue'!

  22. Support Staff 18 Posted by Joel Hooks on 23 Jun, 2011 01:21 AM

    Joel Hooks's Avatar

    What do the 4 columns on each device indicate? Seems like any
    difference is nominal?

    Thanks for doing the analysis. Empirical statistics are awesome :>

  23. 19 Posted by StimuliTV on 23 Jun, 2011 10:24 AM

    StimuliTV's Avatar

    Updated spreadsheet now available.

    Two separate pure actionscript projects were written with almost identical code except for the differences imposed by each framework.

    Two AIR applications were written using exactly the same code to load and profile each test swf.

    One was published for AIR 2.5 (Flex 4.1) to test on Set Top Boxes the other AIR 2.6 (Flex 4.5) for Mobile.

    Each AIR application loads the PureMVC swf then Robotlegs swf then PureMVC again and finally Robotlegs. Each swf tested twice on each platform.

    This test needs enhancing e.g.

    What results happen if Robotlegs is loaded first instead of PureMVC?
    Are there any memory leaks that may affect the results?
    Should a wider range of objects and inheritance hierarchies be tested?

    Blog post and sources available here:

  24. 20 Posted by Stray on 23 Jun, 2011 10:36 AM

    Stray's Avatar

    This is interesting stuff, but the main thing I'm wondering is whether we have a hold on which things matter, and which really don't.

    Obviously fps matters - though I don't think 4/5/6 matters. More like 16 vs 19 would matter - because generally the human eye is fooled by 18 fps and over.

    But yes - which of these differences translate into what kind of different experiences for the end user would be my question.

    We have discussed some strategies for performance improvements in RL2 but it's hard to know what it actually relevant - so this kind of testing is great, but if it can be contextualised then it would be even better.


  25. 21 Posted by Simon Richardso... on 23 Jun, 2011 08:16 PM

    Simon Richardson's Avatar

    [redacted] at Si's request as he needs to get clearance first.

  26. 22 Posted by StimuliTV on 27 Jun, 2011 05:31 PM

    StimuliTV's Avatar

    Thinking aloud, whilst profiling... Is Robotlegs using more memory than PureMVC because of this use of anonymous callbacks??? - there are multiple per view... Would Signals fix this???

    package org.robotlegs.base.EventMap

    var callback:Function = function(event:Event):void
    routeEventToListener(event, listener, eventClass);

  27. Support Staff 23 Posted by Till Schneidere... on 14 Oct, 2011 10:30 AM

    Till Schneidereit's Avatar

    I know this is a very old topic, but since I've got some updates, here goes:

    Swiftsuspenders 2 will use considerably smaller amounts of memory than
    1.x did. Maybe even more importantly, it will create far fewer
    temporary objects during reflection and injection - on the order of
    80% to 90% fewer.

    Having done substantial amounts of profiling on Swiftsuspenders, I'd
    wager that there's almost no memory overhead that's not inherent in
    how IoC containers have to work in Flash, anymore.

    The anonymous callbacks in the EventMaps and some other parts of
    Robotlegs might very well be an issue and we'll certainly work on
    those for Robotlegs 2 (they're also adding to performance overhead).

    Seeing as we're going to work on reducing the frameworks footprint
    anyway, I'm going to close this discussion. Feel free to reopen it if
    you've got important input that you think fits in here, of course.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac