Space leak when app state accumulates? about brick HOT 6 CLOSED

I was able to get the profiler to take library functions into account as well. While I have library-profiling enabled in my global Cabal config, it seems I had to reinstall dependencies with --ghc-option=-fprof-auto -p.

The textual report can be found here.

COST CENTRE          MODULE                         %time %alloc
wcswidth             Graphics.Text.Width             50.6   42.6
str.theLines         Brick.Widgets.Internal          36.8   34.1
txt                  Brick.Widgets.Internal           7.4   19.2
iso10646String       Graphics.Vty.Image               2.0    3.1
unstreamChunks/inner Data.Text.Internal.Lazy.Fusion   1.3    0.0

from brick.

Tentatively, @8e1d7f4 seems to address the issue. Heap Profiler output showing the retainer of allocations showed that renderFinal seemed to be keeping data from being garbage-collected. I don’t know whether this is the best way to address this, but forcing evaluation on the new render state allows the GC to kick in.

The new profile still shows a largish-seeming memory buildup in the str widget, but after forcing evaluation, the memory is successfully GC’ed.

I don’t understand brick well enough to give a well-founded account of why so much memory was retained there. My hypothesis is that when a widget contains computations that don’t actually go into the render (such as the str widget referencing more lines than can be shown on screen), those references are somehow kept around since the GHC run-time doesn’t know that after an image has been rendered, any left-over computations referenced within the rendering code-path aren’t needed anymore.

from brick.

While the GC can now recycle unneeded computations at the point the image is rendered, str still builds up a considerable amount of thunks for very little input. 6330a59 tries to cut this down by limiting line-rendering computations to only those parts of the string that can actually be rendered.

The str widget computations only appear under the category OTHER on the new heap profile.

This adds a dependency on deepseq, but it can probably be done by spraying bang patterns and seqs around.

from brick.

Thank you for the report and the terrific investigation. I tend to hate dealing with space leaks so I especially appreciate that you have gone to the trouble to fix this. :)

from brick.

+1, awesome issue report & fix.

from brick.

Cheers! 😸

from brick.