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] > <javascript:>> 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] >> <javascript:>> 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 >>>>> >>>> >> >
