Author Topic: performance notes from today's bugfixin'...  (Read 3787 times)

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
performance notes from today's bugfixin'...
« on: Mon, Mar 29, 2010 »
So today is a bugfix day for flixel, I should have a nice new dev and master release up in a few hours with lots of fixes and a few new things (but ZERO api changes or deletions).  EN ROUTE, however, I started doing a little profiling (using a new thing in FlxU), and discovered some interesting stuff.  I am using FlxCollisions as my testbed since it's pretty CPU heavy.  Discovered some interesting things about how the CPU/timing was working.  Here are the average times for various operations in FlxCollisions first example (robot and gib spewer) in milliseconds:

1 - Updating all object positions: 3ms
2 - Colliding all objects: 10ms (1ms to build tree, 9ms to walk it)
3 - Rendering all objects: 1ms
4 - Misc Flixel overhead: 1ms
5 - Browser overhead: 25ms!!

I couldn't believe this at first, so I made a new app that had no flixel files, not even a text field or a graphic, all it had was a timer and a trace statement.  Sure enough, the shortest interval you can get out of a timer in the browser is about 24ms or so (on OSX at least).  I made some changes to the flixel game loop which will be detailed later, and ran it locally in the flash player (same FlxCollisions app), and got 150 FPS!!

Ridiculous.  ANYWAYS, this has funny implications for the future of flixel optimization.  On the one hand, it makes flixel's execution speed even more important, but on the other hand, even in the absolute best case scenario I can't even crack 45fps on OSX because of browser BS.

SO...I guess all I'm saying is that I definitely take flixel's performance seriously, and especially in the department of walking the quad tree there is some ground to be made up I think.  But a lot of the other optimizations (vectors instead of arrays, lack of inline functions, method call overhead) seem to be more or less inconsequential.

FINALLY, I have a theory about how to sneak an extra 10fps or so out of the browser performance but I haven't gotten it to work in flixel yet.  I *THINK* there should be a way to basically start the 24ms browser BS timer before stepping through the 15fps or so update, so that the game update loop basically happens during the browser's...whatever time.  However, all my attempts at getting this working are wildly unstable and I'm tired of force-quitting my browser!  If anyone wants to try and get a hack loop like this working I would be very interested in the results :)  I will try again, but probably not anytime soon.

Anyways, hope that helps with understanding flixel performance, and keep an eye out for an update later today!

ShooterMG

  • Member
  • **
  • Posts: 71
  • Karma: +0/-0
    • View Profile
Re: performance notes from today's bugfixin'...
« Reply #1 on: Mon, Mar 29, 2010 »
Very interesting stuff. Did you notice any difference between browsers at all?

vonWolfehaus

  • Active Member
  • ***
  • Posts: 247
  • Karma: +0/-0
    • View Profile
    • Cold Constructs
Re: performance notes from today's bugfixin'...
« Reply #2 on: Mon, Mar 29, 2010 »
Flash performance on OSX is rather infamously bad. (Flash Player 10.1 will fix a lot of that though, so fret not.)

I'd like to do some more tests with Flixel when I get on my next game and I'll post some stuff for that too (before I move to Haxe with a custom version of Flixel for it).

You should try building a Flixel app in Flash Builder and use that profiler for better data, including memory management stuff. I think that's where Flixel is really suffering at the moment.. the destroy() methods are empty. States go through and call destroy(), but after they do that they NEED to set them to null for the GC to pick up.

Quick question: is the quadtree initialized and run even if no collision methods are called? I thought you had to init the FlxQuadTree explicitly to use it?
Meet Obama every day at #flixel on irc.freenode.net.
Use your favorite IRC client or  http://webchat.freenode.net/

L_O_J

  • Member
  • **
  • Posts: 88
  • Karma: +0/-0
    • View Profile
Re: performance notes from today's bugfixin'...
« Reply #3 on: Tue, Mar 30, 2010 »
I'm sorry if I'm probably the only who doesn't get this, but what is "Browser Timer Overhead" ?

Matoking

  • Member
  • **
  • Posts: 57
  • Karma: +0/-0
    • View Profile
Re: performance notes from today's bugfixin'...
« Reply #4 on: Tue, Mar 30, 2010 »
I'm sorry if I'm probably the only who doesn't get this, but what is "Browser Timer Overhead" ?
Overhead time that using a browser adds to the overall frame rate. Like, how much using browser slows the game down.

L_O_J

  • Member
  • **
  • Posts: 88
  • Karma: +0/-0
    • View Profile
Re: performance notes from today's bugfixin'...
« Reply #5 on: Tue, Mar 30, 2010 »
ic, just to be clear, does this related to "timer" or flash in general ? ie.

If I make a flash app with nothing, and just onEnterFrame event handler, with flash.utils.getTimer, and set my frameRate to something like 100 FPS, instead of 10 ms per frame I will get 24 ms (according to adam statement) since the minimal time the browser can get is 24 ms ? Or is it only affect my code if I use flash's timer class ?

If so, IIRC, the devs at adobe is trying to solve this issue in 10.1 by bypassing the browser timer and implement their own ?

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: performance notes from today's bugfixin'...
« Reply #6 on: Tue, Mar 30, 2010 »
1 - the quad tree is only built and walked if you specifically call FlxU.collide() or FlxU.overlap(), or init and walk it yourself.

2 - Yea browser time overhead is weird, and I expect it varies depending on plugin version, platform and browser, but what I tried was creating an empty application with just a timer and a trace statement, and the timer was set to fire every 2 milliseconds.  In the Firefox plugin v10.0.x, 24 milliseconds were passing between each call, rather than 2 milliseconds.  Unfortunately, this is not like...inclusive, it stacks.  So if your game loop takes lets say 10 milliseconds, and then you set a 6 millisecond timer (16ms is ~ 60 fps), that 6 millisecond timer will still take 24 milliseconds to execute, giving you a 34 millisecond total loop time, which is more like 30 fps.

Weird stuff!

I am secretly (or not so secretly) hopeful that there is some way to start that 24ms timer BEFORE doing the 10-20ms game loop update, so that most flixel games would at least run at 40-50 fps instead of 30, but all my attempts to get that to work have been VERY unstable.