-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Performance of @views
with reshape
#29675
Labels
arrays
[a, r, r, a, y, s]
performance
Must go faster
potential benchmark
Could make a good benchmark in BaseBenchmarks
Comments
Thanks for the report. Looks like we're hitting a splatting penalty here… why isn't SubArray's julia> @code_warntype reshapefill(B)
…
│ %53 = (Base.add_int)(%49, %52)::Int64 # computation of linear index
│ %54 = (Core.tuple)(A, 0)::Tuple{SubArray{Float64,2,Array{Float64,3},Tuple{Int64,Base.Slice{Base.OneTo{Int64}},Base.Slice{Base.OneTo{Int64}}},true},Int64}
│ (Core._apply)(Base.setindex!, %54, %53)
… |
dup #29114 |
KristofferC
added
the
potential benchmark
Could make a good benchmark in BaseBenchmarks
label
Oct 16, 2018
KristofferC
pushed a commit
that referenced
this issue
Oct 19, 2018
KristofferC
pushed a commit
that referenced
this issue
Feb 11, 2019
KristofferC
pushed a commit
that referenced
this issue
Feb 20, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
arrays
[a, r, r, a, y, s]
performance
Must go faster
potential benchmark
Could make a good benchmark in BaseBenchmarks
When
view
is used with areshape
in some circumstances there can be a lot of allocation.Consider the following minimal example:
which results in the output
As can be seen when
@views
is used with areshape
there can be a lot of allocations in some situations but not always.Here is my
versioninfo()
Not surprisingly, I see similar performance issues when I replace the
@views
macros with theview
function.The text was updated successfully, but these errors were encountered: