Creating a new sf::Event object in each loop?

[phuongtam]

Hello, everyone! I have a question about most SFML code I see. Why are they redeclaring an sf::Event object after while(Window.IsOpened()). Wouldn't this cause the sf::Event constructor to be called each time creating a new object and hurting performance slightly? Is there any difference in declaring sf::Event before the main window loop?

[Eyfenna]

Did wonder about this myself.
personally I tend to declare sf::Event before the main loop.

[eXpl0it3r]

sf::Event is a POD there's no constructor and this can easily be optimized by the compiler.

[Hapax]

It's also a good example of keeping variables in as local a scope as possible. There is no use to having an sf::Event outside of the window being open so it makes no sense to have one outside of the window.isOpen() loop.

As mentioned, there should not be any performance or noticable performance reduction from creating an sf::Event once per cycle.

However, if you feel that you absolutely must keep from the event being declared every cycle, you can have the best of both worlds (correct scope and persistent life) by simply declaring it as static.

[AlexAUT]

However, if you feel that you absolutely must keep from the event being declared every cycle, you can have the best of both worlds (correct scope and persistent life) by simply declaring it as static.

But static will/may be the slowest, because of cache locality .

As eXpl0it3r said, sf::Event is POD, so creating and instance is done by increasing the stack pointer register by some amount (size of sf::Event (+ padding/alignment)). This usally is done in one CPU-cycle or less. So placing it inside the loop is the best option, because as hapax said, keep variables as local as possible.



AlexAUT

[Nexus]

Totally agree with others: keep variables as local as possible.

This is a typical example of premature optimization. Object creation in C++ is not per se a costly operation, even in the presence of user-defined constructors. What really happens behind the scenes largely depends on the context. Even in languages where there is overhead (most mainstream languages have a GC and objects are created through dynamic allocation), people don't refrain from using objects because they fear the performance hit

Only start worrying about such micro-optimizations once you can prove they matter.

It would of course be a different story if the object being created were more heavy-weight (e.g. of a resource class that performs loading).