Thanks for your response. Patchwork.jl is impressive! This fix almost works, but there is some new issue.
When I first execute, I see the following: Javascript error adding output! ReferenceError: Patchwork is not defined See your browser Javascript console for more details. If I move the slider, the plot appears, but the Javascript error remains. I can however confirm that the memory leak is gone. I've tried removing several .ji files, rebuilding several things, etc. and the error seems to persist. Thoughts? I'm running Chrome on Windows 10. On Friday, November 20, 2015 at 9:48:51 AM UTC-8, Shashi Gowda wrote: > > 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] > <javascript:>> 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 >>>>>>> >>>>>> >>>> >>> >
