Sign in to follow this  

Why is my event queue so fast O_o

This topic is 3556 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This is maybe an dumb question but I ask it anyway. For all the time I used the messages that I got from my WindowProc and everything was fine. My little games run very smoothly and there was no need to change anything but I did it. I implemented an event class that is similar to the event structure from SDL and from SFML. As I run it in release mode it ran much faster than it did before. How can this be? In the WindowProc I add any new event that may be processed by my games into a std::queue and process any pending event in the main loop. Edit: I disabled the timers to see if there is any difference.

Share this post


Link to post
Share on other sites
You're saying it runs much faster in release mode? And that this is a problem?

In general you want to be agnostic with respect to how much processing time your game takes. For example, don't translate an object 5 units every frame; instead, run a timer that calculates the time difference between each frame and translate based on that time. Pseudocode:


time_last = time();
speed = 5;

while (1)
{
time_current = time();
time_delta = time_current - time_last;
time_last = time_current;
object.translation += speed * time_delta;
}


Share this post


Link to post
Share on other sites
Sure, you might have implemented a lightweight version that only contains the features you use.
Such a thing would highly probably be faster when you don't even implement thread safety and other things that more reliable and flexable libraries do.
Have you compared a list of features?
Is it possible you were using the original one inefficiently?

Share this post


Link to post
Share on other sites
Quote:
Original post by megamoscha
This is maybe an dumb question but I ask it anyway.

For all the time I used the messages that I got from my WindowProc and everything was fine. My little games run very smoothly and there was no need to change anything but I did it. I implemented an event class that is similar to the event structure from SDL and from SFML. As I run it in release mode it ran much faster than it did before.

How can this be?

In the WindowProc I add any new event that may be processed by my games into a std::queue and process any pending event in the main loop.

Edit:
I disabled the timers to see if there is any difference.


The difference between debug and release can be huge. Depending on what you do in your message thingy here are a few things that influence performance in debug:
1) heap checking: after every new/delete the heap is checked if you wrote over array boundaries
2) stack checking: not sure if this is done after every function return, but the stack is checked to see if you wrote over stack boundaries
3) array bounds checking: not sure how this is implemented, but when you do array indexing the index is checked against the array bounds.
4) stl assertions: extra checks are done in stl containers in debug mode

Depending how many events you handle in your message handler these things might slow your app down. Probably the std::queue makes a call to "new" when you push_back something, doing a heap check, and makes a call to "delete" when you pop_front and item, doing another heap check. Then you have the extra stl assertions checks.
I can imagine that loads of mouse events are pushed on the stack every frame, and thus doing loads of heap checks.

I once did something similar in a video processing app. I had an std::list with pixels. I pushed pixels on the list while processing a frame. At times I was pushing up to 50,000 pixels on that list and it took half a minute to process one frame in debug mode. In release it ran relatively smoothly (acceptable for what we were doing). The solution to speed up the app in debug mode was to use a pre-allocated array.

For you eventing system you may want to write a simple ring buffer so you don't have to lock the entire array when you are processing the events.

Share this post


Link to post
Share on other sites
I compared the old version with the new version both in release mode. Sorry that I forgot to say that.

@jorgander
Yeah, I want to update my objects in the next minigame that I write. Because I don't like to fix the framerate.

@iMalc
That's what I thought as I woke up today. The old one was just written that it works as I looked at the old version. Funny if you look at your source that you modified a day ago and you are shocked what you were doing in the past. ;-)

@Structural
I'm aware that the debug version adds extra checks to the queue but I didn't thought that so many checks are there. But anyway thank you for your suggestion with the ring buffer. If I'm in the need for more performance and the Event queue is the bottleneck I try to implement it.

++rating

Share this post


Link to post
Share on other sites

This topic is 3556 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this