Entt: Hashing in ENTT_ID_TYPE is not always evaluated as constexpr

[dBagrat]

On VS 2019 (Release) hashing function called every time.

https://github.com/skypjack/entt/blob/b3c568fb6fa46fecbaf77e3b23d5cca7426595de/src/entt/core/type_info.hpp#L60

To force "consteval", we can re-write as:

constexpr auto id = entt::hashed_string{ENTT_PRETTY_FUNCTION};
return id;

[dBagrat]

OMG!
By trying it, I've got a 3-4x speed boost in some system-update loops where I have more registry.get<> (instead of groups/views)

[skypjack]

WTF!? Why on the heart the compiler doesn't always evaluate it as constexpr when it's possible?
Thank you for pointing this out, I never realized this was the case actually.

[skypjack]

Does return entt::hashed_string::value(ENTT_PRETTY_FUNCTION); work as expected instead?

I've got a 3-4x speed boost in some system-update loops where I have more registry.get<>

Granted. While the _standard way_ is a sequential generator, this one relies on hashed strings. If you hash at runtime all the times you need a type, you spend quite a lot for that.
Good catch. :+1:

[dBagrat]

Does return entt::hashed_string::value(ENTT_PRETTY_FUNCTION); work as expected instead?

just tested, unfortunately no.
//It's pity that we don't have a consteval specifier in C++17 :)

[skypjack]

Nvm I'll make it explicitly constexpr as you suggested.
Who knows why it doesn't work otherwise, it's odd.
Indeed, consteval would work like a charm here.

[skypjack]

This is way it wasn't constexpr. :(

[Kerndog73]

@skypjack Apparently that was fixed in GCC 8. Wait, no, nevermind.

[skypjack]

Yup. I'm adding a macro to differentiate between static and constexpr when dealing with gcc. :+1: