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?

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.