squiid/rust
1
0
Fork 0
Code Issues Pull requests Projects Activity

Rollup merge of #40807 - stjepang:optimize-insertion-sort, r=alexcrichton

Browse source 
Optimize insertion sort

This change slightly changes the main iteration loop so that LLVM can optimize it more efficiently.

Benchmark:

```
name                                   before ns/iter   after ns/iter    diff ns/iter   diff %
slice::sort_unstable_small_ascending   39 (2051 MB/s)   38 (2105 MB/s)             -1   -2.56%
slice::sort_unstable_small_big_random  579 (2210 MB/s)  575 (2226 MB/s)            -4   -0.69%
slice::sort_unstable_small_descending  80 (1000 MB/s)   70 (1142 MB/s)            -10  -12.50%
slice::sort_unstable_small_random      396 (202 MB/s)   386                       -10   -2.53%
```

The benchmark is not a fluke. I can see that performance on `small_descending` is consistently better after this change. I'm not 100% sure why this makes things faster, but my guess would be that `v.len()+1` to the compiler looks like it could in theory overflow.
This commit is contained in:
Corey Farwell 2017-03-25 09:30:32 -07:00 committed by GitHub
parent 22f914a09a 2c816f7fb6
commit 2bdbcb0618
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
src/libcore/slice/sort.rs
View file

@ -152,8 +152,8 @@ fn partial_insertion_sort<T, F>(v: &mut [T], is_less: &mut F) -> bool
fn insertion_sort<T, F>(v: &mut [T], is_less: &mut F)
where F: FnMut(&T, &T) -> bool
{
for i in 2..v.len()+1 {
shift_tail(&mut v[..i], is_less);
for i in 1..v.len() {
shift_tail(&mut v[..i+1], is_less);
}
}