Destruction of collections of `CqlValue` is needlessly costly

[pkolaczk]

If you deserialize a collection into a CqlValue e.g. as CqlValue::List which holds a Vec<CqlValue> or if you create a Vec<CqlValue> directly to pass it as a parameter to the driver, the deallocation of such vector can take significant amount of time due to calling the destructors of individual items. This shows as drop_in_place being high in the profile.

The compiler does not know if the items stored in the collection are of primitive type like e.g. CqlValue::Float or more complex objects that must be actively dropped.

This problem could be solved by providing your own wrapper for Vec<CqlValue> that could register if all inserted values are of primitive types at runtime, and if so, could just skip the destruction of them (I'm quote surprised you don't even need unsafe for that!), hence going from O(n) destruction to O(1). Such wrapper then could be used as the representation for CqlValue::List, CqlValue::Set, CqlValue::Vector.

You can look in the #1022 (it is not perfect solution, but I got about 60% speedup on float vectors just from that optimization).

[Lorak-mmk]

I think this may not be needed soon with the deserialization refactor (@wprzytula )

[wprzytula]

@pkolaczk Thanks for pointing out this nonobvious inefficiency!

With the new deserialization refactor (see #1057), CqlValue won't be even created, so its destructor's cost stops being an issue for most users (apart from those who are going to keep using Row and CqlValue for dynamic purposes). Having said that, I believe introducing the optimisation you suggested is not worth the increase in code complexity. Do you agree?