Skip to content

Use sort! where possible #19973

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jan 14, 2017
Merged

Conversation

pabloferz
Copy link
Contributor

@pabloferz pabloferz commented Jan 10, 2017

I noticed here that there are a few places where we are using sort instead of sort!. There are just a handful of them and they are not performance-critical, but the changes were easy enough that I decided to do them anyway.

@kshyatt kshyatt added the performance Must go faster label Jan 11, 2017
@ararslan
Copy link
Member

Would it be worth checking Nanosoldier here or is that pretty unnecessary?

@@ -46,7 +46,7 @@ function sorted_array(m::Dict{AbstractString, Int})
kn[i] = KNuc(elem...)
i += 1
end
sort(kn)
sort!(kn)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this code is used to track performance, it's probably better to leave this change out, to maintain continuity. (I doubt it's that important, though, so I'm open to arguments otherwise...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I guess in this case is better to leave this out.

@pabloferz
Copy link
Contributor Author

@ararslan I don't think there's need to ask @nanosoldier about performance, some of these are related to things like autocompletion in the REPL

@@ -46,7 +46,7 @@ function sorted_array(m::Dict{AbstractString, Int})
kn[i] = KNuc(elem...)
i += 1
end
sort!(kn)
sort(kn)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to say, I don't understand why using sort! here is not ok. We use f.() in the Laplace benchmark now, how is using inplace APIs where available any different than that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's fine to use sort! here. It just means that there'll be a small bump in performance which is only due to changes in the benchmark, not changes in Julia. If one were interested in, say, tracking Julia over time (e.g., like speed.julialang.org used to), this might be important.

We use f.() in the Laplace benchmark now, how is using inplace APIs where available any different than that?

This syntax wasn't previously available in Julia, so the (presumed) speedup is precisely because of the syntax change.

Anyway, I am (and was) nitpicking. In some circumstances, benchmark changes really should be avoided, but for Julia, it should be easy to point to the blip in the k_nucleotide timings and note that it was caused by a change in the test.

And if it's more important to compare with other languages, by all means, this should use sort!.

Cheers!

@StefanKarpinski StefanKarpinski merged commit 325e3d3 into JuliaLang:master Jan 14, 2017
@pabloferz pabloferz deleted the pz/useinplacesort branch January 14, 2017 07:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Must go faster
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants