Okay, that makes perfect sense. Thank you for the quick reply.
On Saturday, May 9, 2015 at 2:51:52 PM UTC-7, Scott Jones wrote:
>
> That's just the garbage collector kicking in every so often... hence the
> "95.18% gc time" and "96.16% gc time" during the two slow runs...
>
>
> On Saturday, May 9, 2015 at 5:24:08 PM UTC-4, Adam Check wrote:
>>
>> Hi,
>>
>> I'm sorry if this issue has been addressed before, but if so, I haven't
>> been able to find it. I am working with julia 0.3.7, using IJulia. I have
>> encountered slowdowns like this in more than one situation. In a minimal
>> working example, I initialize an Array{Float64,1} of size T=100. I do this
>> G=10,000 times. On my machine, this usually takes about 0.002 seconds.
>> However, sometimes it slows down to 0.04 seconds (or even slower). This
>> happens about 1 in 5 times, and I am at a loss for why it happens. Here is
>> the code:
>>
>> function fill_array(G::Int64,T::Int64)
>>> for i=1:G
>>> ones(T)
>>> end
>>> end
>>> @time fill_array(10000,100)
>>
>>
>> If I run it in a for loop, I have:
>>
>>> for i=1:10
>>> @time main()
>>> end
>>
>>
>> With resulting output:
>>
>>> elapsed time: 0.001038927 seconds (8960000 bytes allocated)
>>> elapsed time: 0.001172952 seconds (8960000 bytes allocated)
>>> elapsed time: 0.002866889 seconds (8960000 bytes allocated)
>>> elapsed time: 0.002285146 seconds (8960000 bytes allocated)
>>> elapsed time: 0.050643838 seconds (8960000 bytes allocated, 95.18% gc
>>> time)
>>> elapsed time: 0.001766999 seconds (8960000 bytes allocated)
>>> elapsed time: 0.002487496 seconds (8960000 bytes allocated)
>>> elapsed time: 0.002687758 seconds (8960000 bytes allocated)
>>> elapsed time: 0.001391227 seconds (8960000 bytes allocated)
>>> elapsed time: 0.042945125 seconds (8960000 bytes allocated, 96.16% gc
>>> time)
>>
>>
>>
>> As stated earlier, I have encountered the issue elsewhere before. I
>> believe the last place I encountered it was when taking Cholesky
>> decompositions of matrices. And again, this happens regularly, but as far
>> as I can tell, not in a predictable way.
>>
>> I'm not sure what the issue is. It seems it has to do with memory
>> allocation, even though the number of bytes being allocated is identical.
>>
>> Thanks,
>> Adam
>>
>