-
-
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
Using item from Array{Any} as bound in for loop results in O(N) allocation #5297
Comments
The problem is not the allocation of the range. The problem is the allocation of |
Ah, indeed. That's the whole problem... Though there's still something strange: storing the value in an intermediate variable with a type annotation has no effect. function test3()
x = {1000000, 2}
n::Int = x[1]
for i in 1:n
end
end
julia> precompile(test3, ())
julia> @allocated test3()
15991936 |
Oh, and maybe it would be possible to box the value only the first time? I understand that for each iteration the check will be slower, but since the value of the upper bound does not change, why do you need to allocate it again and again? |
That last one looks like it should work. Not sure what the problem with that is. I'll have a look later. |
Put the ::Int after the x[1], i.e., x[1]::Int. --Tim On Saturday, January 04, 2014 08:59:00 AM Milan Bouchet-Valat wrote:
|
|
@timholy @JeffBezanson Indeed, with Do you think my hypothesis that it would be possible to box the value only once make sense, or should we close the issue? |
We could check the possible "escape" bit to see if the box is free to be reused, and then overwrite it instead of allocating a new one. But that's pretty fancy. |
Closing since this behavior is not unexpected. |
This is something funny which bit me when implementing a frequency table function. It seems that when an element from an
Array
of typeAny
is used to construct the range to loop over, like infor i in 1:x[1]
,x[1]
is accessed at each iteration, which means the allocated memory is proportional to the number of iterations. I would have expected some overhead, but only once, to get the value and construct the range.This is easy to fix by using properly typed arrays, but it was so unexpected that it took me some time to find out where the allocation was coming from.
It doesn't seem to make sense to access
x[1]
on each iteration, since the actual value is not even used: addingx[1] = 1
in the loop does not have any effect.Illustration of the problem:
The text was updated successfully, but these errors were encountered: