4 ms·
Thank you for your reply :), I understand now - you can avoid some of the overhead by not worrying about this for some types (i.e simple ones like i32 without a
by orf 4y ago
Thank you for your reply :), I understand now - you can avoid some of the overhead by not worrying about this for some types (i.e simple ones like i32 without any custom drop/comparators) but there isn’t a way to generalise this and so you’d need to duplicate the implementation.
Interesting. Are you sure the trade-off is worth it? This seems like quite a specialist sorting implementation, restricting it to primitive types or even adding a “please don’t panic” caveat for a 15% performance improvement seems like it would be an OK trade off (even if it’s not very rusty)
- jules 4y agoIf you want your sort to replace the one in the stdlib I imagine you have to adhere to the strict rules.
- kzrdude 4y agoFor some operations it's actually easy to optimize for simple types, because `if std::mem::needs_drop::<T>()` is a valid conditional: https://doc.rust-lang.org/nightly/std/mem/fn.needs_drop.html https://doc.rust-lang.org/nightly/std/mem/fn.needs_drop.html But not everything can be fit into that. But there's a lot that can be done. And a lot of generic code can be omitted when instantiated for simpler types, etc.