-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Use sort! where possible #19973
Conversation
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) |
There was a problem hiding this comment.
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...)
There was a problem hiding this comment.
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.
@ararslan I don't think there's need to ask |
@@ -46,7 +46,7 @@ function sorted_array(m::Dict{AbstractString, Int}) | |||
kn[i] = KNuc(elem...) | |||
i += 1 | |||
end | |||
sort!(kn) | |||
sort(kn) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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!
I noticed here that there are a few places where we are using
sort
instead ofsort!
. 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.