Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / How do you track slow points in your code?

Author
Message
Richard_6
7
Years of Service
User Offline
Joined: 3rd Feb 2017
Location:
Posted: 1st Jan 2018 15:44
Hi everyone! Happy new year!

I'm having some speed issues with my on-going game in some old devices (like iPad 2).

How do you guys find slow points in your codes?

I've tried setting some timers for the critical functions, but the slowest one took 0,000005 seconds even with loops inside (unless the message command doesn't work properly for timer purposes on devices). I'm using getrawtouch() so I can't debug. Every test has to be made directly on the device.

It's not related to fps which is running good at 30 fps. The delay comes when I click on a sprite which triggers a lot of actions and iterations taking about 1 sec.

I appreciate your advices on that.
puzzler2018
User Banned
Posted: 1st Jan 2018 15:51
Hi

Are you using createsprites within your main game loops

This is what potentially causing delays - you could try clone sprite - if its a must or create all your sprites that you potentially going to work
with per level before main game loop starts

I.E

initialise variable
repeat

Inistalise level sprites
Do
do game stuff
Sync
Loop
Delete level sprites
inc level
Until Level > 10

or something along those lines
smallg
Valued Member
18
Years of Service
User Offline
Joined: 8th Dec 2005
Location: steam
Posted: 1st Jan 2018 17:08
make sure you're not loading any images or object files inside a loop, these generally take a while and should be loaded in advance if possible.

if you have any form of loop it will not show in the fps (as you don't generally sync inside these) so these are most likely the cause, if possible remove all loops and change them to a set number of iterations per sync
for example breaking your 'for' loops into parts each frame
i.e.
instead of


do something like this

also exit out of loops as quickly as possible.
taking a few extra frames to run through all your AI logic etc can double your fps without any noticeable effect in game.

also check and clean any other loops you can... (such as repeat until or while loops)

can become something like


you can also use float# = GetFrameTime() to find exactly how long each sync() took
life's one big game
spec= 4ghz, 16gb ram, AMD R9 2700 gpu
Richard_6
7
Years of Service
User Offline
Joined: 3rd Feb 2017
Location:
Posted: 1st Jan 2018 19:28 Edited at: 2nd Jan 2018 00:27
Interesting insights.

@puzzler2018, I'm not creating sprites inside my loops, neither loading images. I'm using setspriteimage() only.

@smallg, Yes I think the problem might be with some loopings. The timer and the fps print literally freeze for a second after I click . However, not sure how can I optimise them. Here are some examples:







This is the biggest one in terms of nested loops but with few items to iterate.


I've tried GetFrameTime() but it freezes when I click just as the FPS.

Maybe the fact that I have used zero global variables, made some functions be called more than once to retrieve variables, but it feels more organised though.
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 2nd Jan 2018 01:50 Edited at: 2nd Jan 2018 01:58
Depending upon how the 'FOR END' value is computed (Before or during iterations) then there could be problem a 4D loop. Assuming AGk2 computes the for loops end value each iteration, then this can indeed blow out the cost of nested loops running on the runtime.

eg..



Assuming FOR loop end expressions are constant (so the loop is same number of iterations each time and isn't changed within the loop) then you should be able to cache the end values and shave off some overhead from the runtime. Variables will cost less than reading a typed structure





Something worth noting is the when you nest structures, you introduce levels of complexity to reading/writing those fields within the structure. While it's logical to nest structures (ie. Pipes[PipePos].TapType[D].TapTurn.Length) it does add overhead onto the back of the runtime. This occurs as the runtime has to compute the position within each level of the structure, the more levels then more overhead per cell.


PlayBASIC To HTML5/WEB - Convert PlayBASIC To Machine Code
Richard_6
7
Years of Service
User Offline
Joined: 3rd Feb 2017
Location:
Posted: 28th Jan 2018 03:39
After a while struggling with this problem, I just figured out what was making the game slow.

As I was using zero global variables, I was passing a lot of type data through arguments during the main loop which somehow consumes a lot of processing. That's the reason the timer wasn't pointing anything relevant. I changed the main types to global and the game is running superfast now.

I will post in the future a performance comparison between using global types versus passing them by argument (ref and value).
MillaSays
6
Years of Service
User Offline
Joined: 15th Dec 2017
Location:
Posted: 29th Jan 2018 14:29
Sounds odd - at least if passing by reference - as that would be the same as a pointer in more common languages. Pointers are a simple 32 or 64 bit values, which should be easy enough to pass around. If not passing by reference however, you make a local copy for the scope - which for a large datastructure will take a lot of cycles.

Globals bypass all this naturally, but they are a female-dog to keep proper track of - so I at least avoid them for any use which is mutable. For constant values (after initialization phase of the app) I'll happily use globals naturally. But for anything likely to change after the init phase I keep datastructures under very tight control.

Login to post a reply

Server time is: 2024-04-20 09:29:45
Your offset time is: 2024-04-20 09:29:45