Jump to content

Gradual performance drop?


NewGuy
 Share

Recommended Posts

Hello again, all.

Started project recently which seems simple enough and difficult to screw up, however, on our Apple devices I'n noticing over about the period of 30 minutes or so, the frame rate drops from 60 to under 20! I'm keeping an eye on instances in the world and they don't increase over time. I thought I had it well contained but it would appear I was wrong.

I guess my questions is, what other things need manual keeping? My sprites/images are well contained I believe, could sounds not being destroyed be the cause?

Cheers for any help

Link to comment
Share on other sites

Without really digging through your code it'll be impossible to target the pain point/s, might be very difficult even through code, I'd recommend using some profiling tools to help pinpoint where any problems might lie.

If its a problem with memory management (i.e. leaks) then you should be able to replicate on desktop (Chrome has the best tools to do this sort of analysis, although there are probably 3rd party stuff that might help if you really wanted to dive into it) although it would tolerate far more abuse before the frames will drop than on a mobile device so the issue might be very subtle on desktop.

Are you running stuff via safari or using something like Cordova/Phonegap? If the latter then you should be able to use xcode to do some pretty thorough analysis via their instrumentation, particularly to see if the CPU, RAM and/or GPU is choking, pinpointing the cause will be trickier but at least instruments will help refine your search for the issue.

Link to comment
Share on other sites

I run my app on the desktop and when it is opened for several minutes I hear the CPU or GPU fan starting to spin very fast! 

Could it be that list of 1500 sprites can cause the CPU\GPU to choke?

What feature of the Chrome browser should help me analyzing problems like that?

 

Thank you :-)

Link to comment
Share on other sites

15 hours ago, shvalb said:

What feature of the Chrome browser should help me analyzing problems like that?

Timeline and profiling tabs are your best bet, both require a bit of knowledge so do some reading on how to understand them.

Looking for memory leaks should be fairly trivial, just start the timeline (or profiler, both have a got a good handle on memory), run it for a while, and check the memory stuff. You can even reach in a bit further and see which functions are being called regularly, that's probably your best bet for trying to pinpoint a memory leak although it can get tricky.

A memory leak will eventually chock up the FPS (I'd guess) but its probably not that. For example, if you were creating and destroying lots of sprites frequently and there was an issue with the destroying then you'd probably call it a memory leak but its the redundant processing that would kill you i.e. a memory leak (in JS at least) is most often referred to when an object goes out of scope (i.e. becomes totally unreachable) but the GC can't clear it because of some obscure references, in effect they are dead objects but not candidates for GC. This will eventually crash your process although you might never see the FPS drop (until its 0 when every goes kaboom).

What is possibly more likely is that those redundant objects are still being referenced somewhere by your code i.e. they are receiving processing (updates, or maybe even renders) when they should not be. For example, if your game involved shooting lots of bullets and you don't clear those bullets properly then there could be loads of redundant bullets getting CPU even though you never see or hear from them. This sort of stuff can be far harder to track but by profiling you'll see execution times for certain functions (or number of calls) gradually rise over time, leading to your FPS shortening.

1500 sprites won't chock the CPU/GPU, even on crap hardware, unless they are super big or something else is going on i.e. check the pixi bunnymark, on my work 2013 macbook air with no GPU I can get up to about 80000 small sprites with no degradation. Stuff like inefficient bounds checking or doing something else like trying to implement boids behaviour poorly (i.e. each entity accessing every other entity every frame) would kill you real quick even with small number of entities/sprites.

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...