If you install Patchwork.jl <http://github.com/shashi/Patchwork.jl>, and re-run your notebook, it should fix this issue. (you might also need to pre-compile Compose again - can be done by removing the .ji file in ~/.julia/lib/v0.4/)
Compose (which Gadfly uses for rendering to SVG) doesn't depend on Patchwork, but if you have it installed, it will use the Patchwork backend when you render a @manipulate of plots - Patchwork will then try to reconcile previously rendered DOM nodes so that there are no performance penalties of this sort. On Fri, Nov 20, 2015 at 10:48 PM, Andrew Keller <[email protected]> wrote: > I think this is exactly what is happening. Some findings: > > 1) run the code: > > using Interact, Gadfly >> @manipulate for φ=0:π/16:4π, f=[:sin => sin, :cos => cos] >> plot((θ)->f(θ+φ),0,25) >> end > > > 2) Chrome dev tools--> Profiles--> heap snapshot. > 3) Click sin, cos, sin, cos, sin, cos, ... sin in the notebook > 4) Take another heap snapshot and look in comparison view. > > It looks like among other things there are a lot of SVGPathElements and > SVGTextElements that belong to detached DOM trees, suggesting the old plots > never get properly disposed. If I instead capture a JS profile in the > Chrome dev tools-->Timeline panel, it appears like the number of nodes and > listeners increases without bound. > > Now suppose I use Winston instead of Gadfly. The memory still appears to > leak, although the plots are a little more lightweight and the leak is > slower. > > Anyway, I'll submit an issue to the jupyter/notebook repo later today > although I wish I could pin down better where exactly the leak is coming > from. > > On Thursday, November 19, 2015 at 10:35:31 AM UTC-8, Keno Fischer wrote: >> >> Sounds like the memory leak is on the browser side? Maybe something is >> keeping a javascript reference to the plot? Potentially a Jupyter/IJulia >> bug? >> >> On Thu, Nov 19, 2015 at 12:01 PM, Stefan Karpinski <[email protected]> >> wrote: >> >>> 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 >>>>>> >>>>> >>> >>
