Let’s start with the fact that regardless of the big-O complexity analysis, which is a nice indicator, you should be benchmarking these things for yourself. You can use
asbenchmark or write your own script to do that.
In (1) you’re changing the list order policy from unordered to order. Append unique to the unordered list is
O(N), then a sort on it is
O(N log N).
Regarding (2), be aware that the third column “Ordered (2) With No Index” refers to an ordered list in a namespace that stores data on SSD, while “Ordered (3) With Offset Index” refers to an ordered list in a namespaces that stores data in memory with persistence. It’s not an index you can build, rather it happens automatically depending on the storage definition of the namespace.
In general, adding/appending/inserting at a specific index position to an unordered list is
O(1). Unordered lists are a better choice if you mostly add data, but don’t get it as often. Ordered lists are useful when you want faster read operations on the data, and are okay with paying the penalty of slower writes.
Again, use this complexity information as a guide. Benchmark the impact for yourself, otherwise choose ordering based on what it does for you in terms of application functionality.