[perf] Use std based dedup in projection

[ishitatsuyuki]

Unstable sort was added recently, and the code that is being modified is 3 years old. As quicksort doesn't allocate it will likely perform as well as, or better than linear search.

I didn't benchmark. Have a perf run.

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[ishitatsuyuki]

Hmm, so basically sorting fails because most types do not implement Ord. Is it a good idea to add derivation of them in this PR?

[kennytm]

@ishitatsuyuki Let's add it, we need a perf check anyway. If it's unacceptable we could use sort_unstable_by_key.

[nikomatsakis]

Seems fine. I'd like to see some perf results, for sure -- even a local run on some non-trivial test case might be of interest.

[ishitatsuyuki]

Unwipped. Please perform a try and/or perf.

[Zoxc]

@bors try

[bors]

⌛ Trying commit c6772b4 with merge 77de396b7685c2d4870314ad7ca865ad7b6feb5c...

[bors]

☀️ Test successful - status-travis
State: approved= try=True

[ishitatsuyuki]

@Mark-Simulacrum please perform a perf run.

[Mark-Simulacrum]

Perf queued.

[ishitatsuyuki]

http://perf.rust-lang.org/compare.html?start=47a8eb7c4e24b61a8a9ab4eaff60ef65291aaa56&end=77de396b7685c2d4870314ad7ca865ad7b6feb5c&stat=instructions%3Au

... and well, surprisingly no noticable time change except one (see below). To sum up, the code is now cleaner and resistant to quadratic blowup, but some Ord implementations are added.

The case where quicksort probably shines:

| clean incremental-opt | 251066587932.00 | 206164489487.00 | -17.9% |

EDIT: this time is quite fluctuating and should not be used as a metric.

[nikomatsakis]

@bors r+

[bors]

📌 Commit c6772b4 has been approved by nikomatsakis