RobotLegs Memory Overhead (Low Spec Devices)
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???
Ta
Comments are currently closed for this discussion. You can start a new one.
Support Staff 2 Posted by Till Schneidereit on 18 Apr, 2011 06:19 PM
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
memory.
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
run-time.
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,
though.
3 Posted by StimuliTV on 18 Apr, 2011 07:47 PM
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?
Cheers
Support Staff 4 Posted by Till Schneidereit on 18 Apr, 2011 08:07 PM
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
framework
- 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.
5 Posted by StimuliTV on 18 Apr, 2011 08:19 PM
I'll get on this tomorrow and post what i find, nice one!
Support Staff 6 Posted by Till Schneidereit on 18 Apr, 2011 08:20 PM
Great! I'm very much looking forward to your findings!
7 Posted by Matt Poole on 19 Apr, 2011 08:43 AM
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.
Support Staff 8 Posted by Stray on 19 Apr, 2011 11:27 AM
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...
Stray
Stray closed this discussion on 19 Apr, 2011 11:27 AM.
Stray re-opened this discussion on 19 Apr, 2011 11:28 AM
Support Staff 9 Posted by Stray on 19 Apr, 2011 11:29 AM
Sorry - clicked the wrong button there! Apologies for double posting and closing. Two f-ups for the price of one it seems!
10 Posted by Paul Robertson on 19 Apr, 2011 04:46 PM
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.
Paul
11 Posted by StimuliTV on 20 Apr, 2011 10:49 PM
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.
12 Posted by Stray on 22 Apr, 2011 04:54 PM
The SS Injector is all lazy instantiation-tastic too. Which also reduces startup loading.
Support Staff 13 Posted by Stray on 11 May, 2011 08:50 AM
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!
Stray
Stray closed this discussion on 11 May, 2011 08:50 AM.
StimuliTV re-opened this discussion on 16 May, 2011 10:44 AM
14 Posted by Aaron on 18 May, 2011 02:50 PM
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.
15 Posted by StimuliTV on 20 Jun, 2011 07:12 PM
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
16 Posted by Stray on 20 Jun, 2011 07:30 PM
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.
Support Staff 17 Posted by Joel Hooks on 20 Jun, 2011 08:07 PM
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.
18 Posted by StimuliTV on 21 Jun, 2011 09:23 AM
Sorry Joel, bad use of terminology... It was always assumed the caching would be the difference not 'an issue'!
Support Staff 19 Posted by Joel Hooks on 23 Jun, 2011 01:21 AM
What do the 4 columns on each device indicate? Seems like any
difference is nominal?
Thanks for doing the analysis. Empirical statistics are awesome :>
20 Posted by StimuliTV on 23 Jun, 2011 10:24 AM
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:
http://deceptiveresolution.wordpress.com/2011/06/23/framework-profi...
21 Posted by Stray on 23 Jun, 2011 10:36 AM
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.
Stray
22 Posted by Simon Richardson on 23 Jun, 2011 08:16 PM
[redacted] at Si's request as he needs to get clearance first.
23 Posted by StimuliTV on 27 Jun, 2011 05:31 PM
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);
};
Support Staff 24 Posted by Till Schneidereit on 14 Oct, 2011 10:30 AM
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.