[C++] pleasant but unexpected surprise
Author
Hi, all!
Ok, so i'm doing just another 2D action platform which takes some computation in order to make it right. More computation means less FPS, essentially, right?
Anyway, i decided to implement a feature, which allows the player to shoot more than one bullet(whoa, what a feature...) and some more advanced(not really) collision detection methods.
But before i implemented all that, i checked my current FPS counter and it said:"117"
Now i implement these things in my Engine class and the FPS drops down to 105.
So i say... okay, i didn't use the best algorithm and i probably implemented it wrong(read: not efficient).
And now i move all the variables and data structures to the Player class, since it belongs there anyway, and i write ~10 get/set functions for access back in Engine class.
Now i only have to replace all the var names with get/set functions and it will work.
In the mean time i was thinking:"omg, this will be so slow :x".
So i fixed all the compiler errors, and ran the app.
I got 115-117 FPS :o
My question:
How can this be possible? shouldn't all those calls to other class' methods be slower?
I mean, i have a new Bullet object being created every time the user clicks on LMB and then that object is being passed onto one of those method to finally push_back into a list data structure.
I even have a new Bullet object created every iteration(when i check for collision).
isn't that wasteful and slow? am i missing something?
Thanks!
FPS is a bad measure of performance, because it incorporates too many factors. A small modification might increase performance here but decrease it there, or vice versa. People generally use a profiler to determine performance limitations in code and target them for optimization individually.
You can generally call thousands or tens of thousands of functions without noticing a reduction in performance. And if the function is inlined, there will be no reduction at all.
You can generally call thousands or tens of thousands of functions without noticing a reduction in performance. And if the function is inlined, there will be no reduction at all.
why is drop of 117 to 105 , which is less than a millisecond a frame, performance slow down since you added features that require overhead? As far as the other changes you made restoring performance, I couldn't tell you with out a profiler. More than likely you are being limited by other code not the code in question, probably the blitter. Second since the getter/setter were so small they probably got inlined meaning no function call overhead.
That is a little unclear, perhaps with some code we could see what happened... For the moment I have no idea about how it was implemented in the first time.
Perhaps your had something running in the background when you got 105 fps, perhaps your code did it, but without any code it will be hard to tell.
Perhaps your had something running in the background when you got 105 fps, perhaps your code did it, but without any code it will be hard to tell.
Author
Quote:Original post by ToohrVyk
FPS is a bad measure of performance...
actually, i never thought of that, but now it seems logical to me, heh.
i have profiled a bit, and it seems that the collision checks take 40% of the time, whilst before all the changes, the Input system took most of the time.
also, all the bullet-related stuff was pretty low on the list, so i guess the problem was elsewhere!
Perhaps you are doing something less often now? Its also possible that before, something was being constantly paged in and out (if you have a large number of projectiles this can happen) but its being paged out a lot less now.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
