Home → Problems →

RL1.5 Performance issue

• Edit

Dev

26 Jul, 2012 10:58 PM

Hi,

I'm new to RL, using it for the first time on my on going project. Project is medium level of complexity and size. And contains 8-10 views with their respective mediators. Everything is working fine, except, the over all performance.
I mean, when switching views, by any action, it takes 2-3 seconds to load the new view and if you have transitions implemented it goes even worst, this scenario is on normal machine (2 gh intel, 4gb Ram, win7, 64 bit).
However on faster machine it works well, but thats not most likely for every user.
FYI: Every view generates upto 1000 graphical components(custom comps, MXML skins), data parsing for them and then display.

Any suggestions if its RL or some bad approach. However I followed the steps properly to use RL.

Thanks,
Dev

1. 1 Posted by Jos Yule on 26 Jul, 2012 11:38 PM

   

   Um. So, you are creating 8000 to 9000 MC-like (or more complex) objects, and you are experiencing a slow down? That is a lot of UI elements. Have you tried to create these UI elements without or outside of RL? IE. is the slow down perhaps simply do to the number of items being rendered/instanced?

   Perhaps turn off auto-mediation? I'm hoping that you are not mediating each of these UI elements, but some parent element. I know that the auto-mediator listener can slow things down where there are a lot of items being added to the stage at the same time.

   • Edit

2. 2 Posted by Michal Wroblews... on 27 Jul, 2012 12:54 AM

   

   Hi, It's because of Robotlegs Automediation of views. Every added element is parsed. Check out this thread about the same topic. http://knowledge.robotlegs.org/discussions/problems/65-massive-perf...

   Regards,
   Mike

   • Edit

3. Support Staff 3 Posted by Shaun Smith on 27 Jul, 2012 01:44 AM

   

   Hello,

   Robotlegs auto mediation does indeed slow things down a little, but only when the app is already in trouble. In other words, the performance impact is greatest when the app already has too many deeply nested or densely packed views, in which case the Flash Player struggles anyway.

   In Flex it's incredibly easy to create deeply nested views - HGroups nested inside VGroups nested in Skins wrapping components etc etc. Even without Robotlegs in the picture it's always important to aim for the flattest structures possible. The ConstraintLayout is a great way to keep your layouts flat instead of nesting HGroups and VGroups. Have a quick read though this: http://www.adobe.com/devnet/flex/articles/flex-mobile-performance-c...

   If you have a moment, and are willing, you could run a little tool I wrote that grabs some stats relating to the complexity of your app's display list: http://shaun.boyblack.co.za/blog/2011/08/16/show-me-your-tree/

   Be sure to run the tool when your app is at its most complex (i.e. when the most view components are on stage). Also, have a look in the comments of that blog post to get a feel for the complexity of some real world Flex/Flash apps.

   Once you've flattened your layouts, skins and components, your app should run smoothly with or without Robotlegs.

   Hope that helps.

   • Edit

4. 4 Posted by Dev on 27 Jul, 2012 02:03 AM

   

   Hey guys,

   Thanks a lot for your comments,these are really helpful.

   Shaun,

             I agree what you said..I tried your tool on one of my app's View and below is the stat, can you please let me know, what does this mean now?
   

   FYI: its an AIR App in FB4.6

   All Container Stats
   Containers: 795 total
   Children per container: 51 max, 1.35 avg
   Depths (distance): 10 max, 5.78 avg
   Unique container types: 48 total

   Unfiltered Container Stats
   Containers: 257 total
   Children per container: 9 max, 0.74 avg
   Depths (distance): 8 max, 5.48 avg
   Unique container types: 27 total

   Filtered (mx., spark., flash.) Container Stats
   Containers: 538 total
   Children per container: 51 max, 1.65 avg
   Depths (distance): 10 max, 5.92 avg
   Unique container types: 21 total

   Thanks
   Dev

   • Edit

5. Support Staff 5 Posted by Shaun Smith on 27 Jul, 2012 11:26 AM

   

   You can install this utility: https://github.com/eidiot/robotlegs-utilities-LazyMediator

   And then add this to the declaration blocks of any view components that need mediation:

   <LazyMediatorMxmlActivator view="{this}" />
   

   The utility turns off auto-mediation, and the tag makes view components dispatch relevant events. Give it a try (you said you only had 8-10 mediated views, so it shouldn't take long to put in place), and let us know how it goes. If it doesn't help much, then your layouts are simply too complex. Even if it helps, I'd still recommend trying to optimise all your view components, layouts, skins etc.

   • Edit

6. 6 Posted by Dev on 28 Jul, 2012 05:42 PM

   

   Hey Shaun,

   Thanks for this, I tried using this utility, not sure if I implemented it correctly, here is what I did.
   1. In custom Context, which is extending the Context Class, I override the mediatorMap getter method with "return _mediatorMap || new LazyMediatorMap(contextView, injector, reflector));"
   as described in read me file on github.

   And then added the to all the view components which are being mediated.

   rest of the old RL implementation is same, I didn't modify any other stuff related to RL's mapEvent, mediatorMap, mapCommand etc.
   Things are working fine, but I don't see any change in performance, please correct me if I implemented it wrong.

   I am going though the view components optimization as well, but I hardly see any section that needs any further optimization. All the layouts are simple having 2-3 main containers(s:Group) and adding things at run time to them (custom components to display data with some MXML graphics/skins).

   Thanks for the Help!

   Thanks
   Dev.

   • Edit

7. Support Staff 7 Posted by Shaun Smith on 28 Jul, 2012 05:53 PM

   

   Hi Dev,

   Hmm.. it sounds like you implemented the Lazy utility just fine, but as it doesn't improve performance, then it is not auto-mediation or the framework that is slowing things down. In which case the only thing you can do is carefully analyse what is going on through a Profiler. Something is causing the performance problems - it could be anything really. I'm afraid I can't help much with this, you'll just have to dig in as deep as you can. Best of luck!

   • Edit

8. Ondina D.F. closed this discussion on 27 Aug, 2012 10:38 AM.