Skip to main content

Timeline for Optimizing List<string> performance

Current License: CC BY-SA 4.0

21 events
when toggle format what by license comment
Dec 23, 2022 at 23:44 history edited L.B CC BY-SA 4.0
added 96 characters in body
Dec 23, 2022 at 23:32 history edited L.B CC BY-SA 4.0
added 36 characters in body
Dec 23, 2022 at 23:19 history edited L.B CC BY-SA 4.0
added 4 characters in body
Dec 23, 2022 at 23:12 comment added L.B @Mast thanks.. updated...
Dec 23, 2022 at 23:11 history edited L.B CC BY-SA 4.0
added 36 characters in body
Dec 23, 2022 at 23:02 history edited L.B CC BY-SA 4.0
added 9 characters in body
Dec 23, 2022 at 22:55 history edited L.B CC BY-SA 4.0
added 9 characters in body
Dec 23, 2022 at 22:49 history edited L.B CC BY-SA 4.0
added 3715 characters in body
Jan 15, 2022 at 11:42 comment added Mast I realize this is an old answer, but the value of the answer would be improved by summarizing what you did differently in your version compared to the original and why that's better. The current (well documented) code is behind a link and links rot. Currently the only difference stated in the answer is that your approach is not keeping all items in memory, but that's not the only difference.
May 23, 2017 at 12:40 history edited CommunityBot
replaced http://stackoverflow.com/ with https://stackoverflow.com/
Mar 8, 2012 at 14:54 comment added tvanfosson I should also add that my comment wasn't directed at this particular question, but rather meant as a caveat for anyone who finds this later and is doing a key-based sort rather than sorting on the entire element. I just thought people should know that it's not a drop in replacement IF stability is important.
Mar 8, 2012 at 14:30 comment added tvanfosson Right, but consider the case where you have a set of log entries that you know are ordered by time. You want to find the first 5 log entries whose description starts with the word error because you want to see where a problem started. A simple scan is probably the way to do it, but let's say you order them by description and then take the first five. In this case a stable sort is critical because you want to retain the relative ordering by time. I'm not saying that your method is wrong, just that you have to understand whether it's appropriate or not.
Mar 8, 2012 at 13:45 comment added L.B @tvanfosson Just forget the implemantation details for now: The idea is: You can find the Max(or Min) item of a List in O(n) time. if you extend this idea to m item(5 in the question), you can get top(or buttom) m items faster then sorting the list(just in one pass on the list + the cost of keeping 5 sorted items)
Mar 8, 2012 at 13:39 comment added tvanfosson HeapSort is known to be a non-stable sort. If the priority queue implementation uses the same heap data structure (which the docs seem to suggest), then I would expect that it would have the same characteristics. Note that your test wouldn't detect this as there is no way to tell the difference between identical keys sorted in a different relative way. Attach a bit of unique data to each key and compare the order of those data elements and see if it's still in the same relative order. According to the docs, OrderBy uses a stable sort.
Mar 8, 2012 at 13:30 comment added L.B @tvanfosson If you'd taken a look to PerformanceTest(Assert code), you would see that it produces exactly the same output as OrderBy().Take()
Mar 8, 2012 at 13:15 comment added tvanfosson I suspect that the use of the PriorityQueue makes this a non-stable sort. If you need to retain the relative ordering of items with "equal" prefixes, you probably shouldn't use this.
Mar 7, 2012 at 19:18 history edited L.B CC BY-SA 3.0
added 224 characters in body
Mar 7, 2012 at 17:55 history edited L.B CC BY-SA 3.0
added 3 characters in body
Mar 7, 2012 at 17:46 history edited L.B CC BY-SA 3.0
added 13 characters in body
Mar 7, 2012 at 17:39 history edited L.B CC BY-SA 3.0
added 2 characters in body
Mar 7, 2012 at 17:34 history answered L.B CC BY-SA 3.0