3.0.1 Lack of optimization

[nameles01]

Hello Aren,

I'm currently attempting to migrate a project from 2.6.3 to 3.0.1 as it solves a lot of issues and implements features that have been requested by the rest of our production team.

I've managed to get 3.0.1 to compile our current suite of games, however the performance has taken a big hit ( from 40 to 9 fps ).

While looking through the code I noticed it doesn't seem too optimized yet, most obviously in the form of variable declarations occuring within the scope of for loops.

e.g.:

for( int index = 0; index <array.length; index++ )
{
     UIDrawCall dc = array[index];
}

instead of:
UIDrawCall dc;
for( int index = 0; index <array.length; index++ )
{
     dc = array[index];
}
 
I was wondering what the status on that ( and other possible script optimizations ) is - are you still too busy building the feature set and bug fixing and is it coming later or will it stay this way?

Since we're developing our games for Unity-> Flash export these things affect us much more heavily so we're very interested in your response. We are aware you no longer support Flash and it's use is at our own risk.

Thanks for a great product!

Leon

[ArenMook]

Minor things like having a variable be inside the loop doesn't matter in that case as it's just a reference. If anything, performance should have improved by going up to 3.0 rather than go down. I'd appreciate it if you investigated it to determine what's holding it back.

[mishaps]

my experience is an improved framerate with 3.0

[nameles01]

Hello Aren,

Thanks for the quick response.

I do believe a memory address becomes allocated for that type each time you declare a variable. Moving it outside the for scope will make this only occur once instead of array.length times.

In our specific case we know from our conversations with Unity developers that the Flash compiler will convert each newly declared variable into a different internal type that can be used by the Unity engine. This conversion creates a lot of overhead on variable declaration in Flash.
This is especially true for value types as they are created and converted each time they are passed. Reference types will point directly to the converted internal variable once converted and only undergo this overhead once.

I've done a quick ( and hugely ugly ) optimization sweep in UIPanel and UIWidget to move all variables instantiation outside of for loops and even outside of method scopes ( ugly! ) so that they occur as infrequently as possible but unfortunately haven't gained more than a few % of script performance.

Currently the biggest bottleneck I can find using a performance profiler (adobe Scout) on my swf file has to do with equality operators. I noticed some overrides for those and will see if I can optimize any of those. I must note that the results from Adobe Scout are hugely cryptic so its hard to pinpoint a bottleneck.

I'm unsure how much time i'll be allowed to allocate to the task but will keep you updated on any progress.

Attached is a screenshot of Adobe Scout with a cryptic call stack time measurement. Half of the functions are mumbo jumbo but they do all end up in some Equality / InEquality / Compare object call that originates in UIPanel and UIWidget. Any advice you could give me on changes that could cause this would be much appreciated.

[nameles01]

Hello Aren,

I've spent all day attempting to optimize 3.0.1 for Flash. My final result is 37.8 fps with 3.0.1 vs 40.2 with 2.6.3.
For everyone, it should be noted that Flash can handle a large number of draw calls just fine - it is script execution causing the fps drops. The optimization that NGUI does to reduce the amount of draw calls is actually a performance hit in Flash Therefore my methods and results most likely do not apply to other platforms.

The additional things I've tried ( based on what I said above ):
Remove any.Equals() calls and replace them with the simple == operator and replace the .Compare() and the Sort() operations with manual sorting.
As expected the Equality / Inequality / etc. time decreased, however the total frame time stayed the same. i.e.: Adobe Scout wasn't telling me what's really wrong...

At that point I implemented some timed logging to find the bottleneck myself and found it was caused completely by UpdateDrawCalls(), notably the assignment to dt (Transform) and dc(UIDrawCall) at the end. Which is simply doing exactly what it's supposed to...

Finally I took to changing the setup of the GUI in one of our games. I found that the amount of panels you use makes a huge difference in 3.0.1 whereas it did not in 2.6.3.
I removed about 40 panels, of which a lot where nested under another panel.
In the end I went from ~7 fps out of the box to ~12 fps with a lot of hacking / optimization and finally to 37.8 by decreasing the amount of panels.

[ArenMook]

Yes, panels can cause draw calls to be broken up in sometimes rather unexpected fashion. 3.0.2 remedies it by adding an explicit depth value to the panels that you can set, forcing all their content to be in front or behind others, but if it matches, and widget depth also matches, and the widgets lie in different panels... this can often lead to a lot of extra draw calls and work needed to be done by the panels.

[nameles01]

Hi Aren,

Thanks, thats very useful. I have yet to correctly set all the depths and so a great deal of them share the same depth. Although I now need to switch to other tasks before being able to continue this I'll let you know how it goes once I can try it.