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
>>
>

Reply via email to