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
>
