Use sort.Slice instead of sort.Interface?

Question

Use sort.Slice instead of sort.Interface?

ashi009 opened this issue 7 years ago · comments

Xiaoyi commented 7 years ago

I've done some benchmark on both. It seems that sort.Slice has 20% performance improvement comparing to sort.Interface.

However it means stop supporting go 1.7 and earlier versions.

Shawn Smith commented 6 years ago

Merged!

Shawn Smith · Answer 1 · Sun Feb 26 2017 08:44:43 GMT+0800 (China Standard Time)

It's an idea worth looking at for sure, though the use of .Sort() is kind of a "you're using it wrong" backup to avoid the large upfront costs of radix sort, so I don't think at this time it is worth moving the min version from 1.2 to 1.8. But when 1.9 is out...

…

On Sat, Feb 25, 2017 at 3:47 PM, Xiaoyi ***@***.***> wrote: I've done some benchmark on both, it seems that sort.Slice has 20% performance improvement comparing to sort.Interface. However it means stopping support for go 1.7 and earlier versions. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABHJUxDpBeHXuwzPWEZtko1Q-CyFI_mmks5rgL2sgaJpZM4MMLhY> .

Xiaoyi · Answer 2 · Sun Feb 26 2017 18:35:21 GMT+0800 (China Standard Time)

Good point. Closing this.

Shawn Smith · Answer 3 · Mon Jun 25 2018 02:47:28 GMT+0800 (China Standard Time)

With vgo coming, I'm starting to tag releases. The existing code has been cleaned up some and tagged as "v0.1". I'm reopening this as a feature request for "v0.2", as doing this will not break any working code unless its built with an old Go. This is a change that, while somewhat risky, isn't the same as breaking API compatibility and doesn't warrant a full new major point release.

Go moves pretty fast, and I encourage all shops to strive to keep up with Go releases, but let's use Ubuntu LTS support as a sort of relative benchmark for how long we want to support builds on old Go versions.

Ubuntu 16.04 LTS is good until April 2021, and it came with Go 1.6, which includes support for the vendor folder (>=1.5). So a solution for these users, and any on versions >= 1.5 but <= 1.7 is to vendor a clone at the v0.1 tag until they can upgrade to 18.04 LTS / Go 1.10.

This will break builds on 14.04 Trusty, which is good until April 2019 and came with Go 1.2, which is currently the low bar for test builds in travis. This makes me uncomfortable with releasing this change until closer to that time. But we should be ready to switch to sort.Slice() when the last semi-reasonable excuse to still be running Go 1.2 expires.

Xiaoyi · Answer 4 · Tue Jun 26 2018 14:43:22 GMT+0800 (China Standard Time)

Go 1.6 is no longer maintained, and will not receive any security upgrade: https://github.com/golang/go/wiki/Go-Release-Cycle#release-maintenance

I don't think LTS means "use all the ancient dev tools to get stability".

Shawn Smith · Answer 5 · Wed Jun 27 2018 06:04:50 GMT+0800 (China Standard Time)

That's why I said "semi-reasonable". It is a pretty weak excuse. It would be more than reasonable for me to release this change "early".

Mark Kubacki · Answer 6 · Thu Dec 12 2019 02:44:31 GMT+0800 (China Standard Time)

FYI, the increased speed is primarily due to Go skipping array-bounds checks in its swapper. An optimization that is not available to third-party packages, where those checks are always generated by the compiler.