This should work – if there's a memory leak that's never reclaimed by gc, that's a bug.
On Thu, Nov 19, 2015 at 11:55 AM, Andrew Keller <[email protected]> wrote: > 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]> >> 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 >>> >>
