`storage::clear` or `storage::pop_all` optimization

[jeanlemotan]

Hi,

First of all, thanks for this awesome lib. We're building an engine on top of it and it's going great.
There is one issue that is bugging me while profiling: clearing a storage with tens of thousands of components is very slow. Like 1.37ms for 60K entities, which is comparable to computing and adding those components in the first place.
The component in question is a POD with no destructor:

struct VisibilityStats
{
	float cameraDistanceSq = 0;
	float screenRatioSq = 0;
	Lod lod = k_bestLod;
};

I've seen that the pop_all function which seems to do all the work goes item by item to destroy the components, but it also swaps and pops, which seems unnecessary? After all, we're clearing, so that seems like something that can be skipped.
I'm still familiarizing myself with the code though, so maybe I missed something.

[skypjack]

So, you know what the problem is? Non-trivial destructors can reference the storage itself, and this design was born from these very uses. Therefore, destruction must be controlled and clean, one step at a time, one element at a time.
However, I think you raise a good point here. If the class has a trivial destructor (and we know it at compile-time), we're confident we can delete everything more quickly. And that's certainly the majority of cases!

I'm leaving this issue open as a reminder for this change. What do you think?

[jeanlemotan]

Ok, that makes sense, 100%.
Having a specialization for the trivial destructor case should cover most cases indeed.
I'd add that there could even be an clear_unsafe method that assumes the destructors don't reference the storage, and let the user choose, for those rare cases. But not sure if this is in line with the design and guidelines of entt though.
Thanks a lot for the info.

[skypjack]

May I ask you what version of EnTT you are using?
A test on a real world case would be good to confirm the optimization eventually.