I totally agree with this. It is exactly why I initially called this function darkritual; I am sacrificing my sanity to get some performance improvements. I think this is an unfortunate reality that you sometimes need this kind of do-nothing “nudge” to the compiler (e.g., FastClosures.jl). I do want to throw away this kind of hacks as soon as possible . But if I can write “zero-cost” abstractions with a little hack like this, I think the situation is not so horrible.
By the way, fortunately for us, there is an open PR to fix (some of?) the problem:
So let’s hope that we can forget about it pretty soon.
As @vchuravy mentioned above, there is a (possibly) different class of problem “solvable” by restack. Here, just re-creating Tuple{Set{Int}, Vector{Int}} at the end of the function somehow helps the compiler generating a better code. It seems this case is more related to your post on StackOverflow?
Thanks, that’s a good point. I think UnsafeArrays.jl is a more direct solution if you know you are working on arrays. Restacker.jl is more general as it works with any objects (e.g., there is an example with Set). But, due to this generality, I imagine it is likely less powerful than UnsafeArrays.jl in some situations.