It does discuss performance and points out some places where the Haskell implementation makes the natural naive solutions performant. > While it's true that so

It does discuss performance and points out some places where the Haskell implementation makes the natural naive solutions performant. > While it's true that sort has an O(nlogn) performance profile, one interesting thing here is that sorting is lazy in Haskell! This means that if our two strings are unequal, they will only be sorted far enough to determine inequality! I don't understand exactly how this works - don't all O(n log n) sorting algorithms still have to do some work on the other elements of the list before pulling out the smallest one? If you just scanned and pulled the smallest one to the front each time that is O(n^2). And there's an implementation detail here that differences at the start of the sorted string will be caught more quickly than at the end, so real-world behaviour is dependent on your choice of sort order. Agreed that the performance analysis is quite superficial and that some of the solutions like sum NToTotal must be very sub-optimal.