Maybe generating a new plot every time is not great practice, on account of 
the performance hit. That being said, I think it's perfectly legitimate to 
do what I'm doing for prototyping purposes. I can achieve the frame rate I 
want and the main example shown on https://github.com/JuliaLang/Interact.jl 
does the same thing I do, generating a new plot each time.

In fact, I'd encourage anyone reading this to just try that example, and 
repeatedly click between sin and cos. I'm able to make the memory 
consumption of my browser grow without bound. Surely someone besides myself 
has noticed this before! I don't think loading another package is a serious 
solution to the problem I'm describing, although your package certainly 
looks useful for other purposes.

Just to reiterate, this is not a small memory leak; this is like a memory 
dam breach. I'm happy to help debug this but some assistance would be 
appreciated.


On Thursday, November 19, 2015 at 7:11:55 AM UTC-8, Tom Breloff wrote:
>
> You're creating a new Gadfly.Plot object every update, which is a bad idea 
> even if Gadfly's memory management was perfect. Plots.jl gives you the 
> ability to add to or replace the underlying data like this:
>
> using Plots
> gadfly()
> getxy() = (1:10, rand(10))
> plt = plot(x, y)
>
> # overwrite underlying plot data without building a new plot
> plt[1] = getxy()
>
>
> You can also use familiar push! and append! calls. 
>
> Let me know if this helps, and please post issues if you find bugs. Of 
> course the memory issue could be while redisplaying in IJulia, in which 
> case this method won't help. 
>
> On Thursday, November 19, 2015, Andrew Keller <[email protected] 
> <javascript:>> wrote:
>
>> I'd like to use Interact to have a plot that updates frequently in a 
>> Jupyter notebook, but it seems like there is a large memory leak somewhere 
>> and I am having some trouble tracking down what package is responsible. 
>> Within a few minutes of running, the following code will cause the memory 
>> used by the web browser to balloon to well over 1 GB with no sign of 
>> slowing down. It is almost like the memory allocated for displaying a 
>> particular plot is never deallocated:
>>
>> using Reactive, Interact, Gadfly
>>
>> @manipulate for 
>>>     paused=false,
>>>     dt = fpswhen(lift(!, paused), 10)
>>>     plot(x=collect(1:10),y=rand(10))
>>> end
>>
>>
>> I can observe this problem using Julia 0.4.1, together with the most 
>> recent releases of all relevant packages, in either Safari on OS X or 
>> Chrome on Windows 10.
>>
>> Here's hoping someone has an idea of what's going on or advice for how to 
>> track down this problem. It seems like something that many others should be 
>> experiencing.
>>
>> Thanks,
>> Andrew
>>
>

Reply via email to