Open roflmaostc opened 2 years ago
I'm affraid this is not a false positive of Anti-aliasing
.
Profile shows that the time cost during the first call could be equally (almost) divided into:
p = A .> v
B = view(A, p)
(It do 'collect' during ensure_indexable
, I think the extra allocation comes from here).B .= NaN
or fill!(B, NaN)
For the second and third call, A
has been updated, so A .> v
return a all false
BitArray, thus the last 2 part go away.
Yeah but why should there be a copy in step 2?
The update is in-place and we are definitely don't assign a copy but instead the original one. That seems to wok well.
Might be similar to https://github.com/JuliaLang/julia/issues/30041.
Good to know we aready have a issue to track this.
But improvement might be hard, as the current api returns a Subarray
.
If we can't prove there's no further access on the Subarray
, the collect of LogicalIndex
seems unavoidable. (Edit: But looks like we can use findall
to make it faster, see https://github.com/JuliaLang/julia/issues/30041#issuecomment-996708441)
Hi!
I encountered an anti-aliasing bug:
See, on
, this example:
So whenever (first run) we really do an assignment (with the
BitArray
) it falsely copies the right hand side (the 305MiB). In further runs (BitArray only 0s), nothing should be done and it also doesn't copy it.We should be possible to prevent this, right?
Best,
Felix
Further reference: