Bug 460253

Summary:	Very high memory usage (memory leak?)
Product:	[Applications] ghostwriter	Reporter:	Riccardo Robecchi <sephiroth_pk>
Component:	general	Assignee:	megan.conkle
Status:	CLOSED NOT A BUG
Severity:	normal	CC:	89q1r14hd
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Neon
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Riccardo Robecchi 2022-10-11 16:06:25 UTC

SUMMARY
Hello! I have noticed that Ghostwriter uses over 400 MB of memory even with relatively small documents (~700 words) that only contain text, so with no images or other complex media in them. This is a very high usage for a program that ultimately is only managing text. Closing Ghostwriter and reopening it with the same document being displayed uses about 200 MB of memory, which seems to indicate there is a memory leak somewhere.

STEPS TO REPRODUCE
1. Open Ghostwriter
2. Type for a few minutes

OBSERVED RESULT
Memory usage gets very high.

EXPECTED RESULT
Memory usage stays low.

SOFTWARE/OS VERSIONS
Linux: KDE neon
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Ghostwriter version: 2.2.0

ADDITIONAL INFORMATION

Comment 1 megan.conkle 2022-10-12 16:46:58 UTC

Hi Riccardo,

ghostwriter uses Chromium to render the live preview.  I believe that should explain the 400MB of memory that is consumed.

I'd like to go with something lighter, but if I do then I can't support MathJax or any other JavaScript goodies.

Comment 2 Riccardo Robecchi 2022-10-20 16:32:15 UTC

(In reply to megan.conkle from comment #1)
> Hi Riccardo,
> 
> ghostwriter uses Chromium to render the live preview.  I believe that should
> explain the 400MB of memory that is consumed.
> 
> I'd like to go with something lighter, but if I do then I can't support
> MathJax or any other JavaScript goodies.

Thanks for the explanation. However, even with the HTML preview pane disabled, memory continues to climb - at the moment it is over 600 MB. Is this to be considered normal? Shouldn't disabling the HTML preview actually not load it at all, to reduce memory usage?

Comment 3 megan.conkle 2022-10-20 22:45:54 UTC

(In reply to Riccardo Robecchi from comment #2)
> (In reply to megan.conkle from comment #1)
> > Hi Riccardo,
> > 
> > ghostwriter uses Chromium to render the live preview.  I believe that should
> > explain the 400MB of memory that is consumed.
> > 
> > I'd like to go with something lighter, but if I do then I can't support
> > MathJax or any other JavaScript goodies.
> 
> Thanks for the explanation. However, even with the HTML preview pane
> disabled, memory continues to climb - at the moment it is over 600 MB. Is
> this to be considered normal? Shouldn't disabling the HTML preview actually
> not load it at all, to reduce memory usage?

The HTML preview is never truly disabled.  It is always there being refreshed in the background.  This makes it snappier when you choose to show it.  If you do some research on it, you will find that Chromium/Chrome does tend to grow in memory even just sitting there drooling.  It doesn't look like it's leaking memory, but just being greedy.