Drastic increase in memory usage on develop

[Jacalz]

Checklist

• I have searched the issue tracker for open issues that relate to the same problem, before opening a new one.
• This issue only relates to a single bug. I will open new issues for any other problems.

Describe the bug

I noted during some testing that the memory usage seems to have roughly doubled between v2.2.4 and develop (to be v2.3.0). I initially launched fyne_demo and it had a 1.6x increase but switching the view resulted in it becoming a 2x increase:

I observed a very similar 2x increase in Rymdport but at initial start without pressing anything.

How to reproduce

1. Open fyne_demo on master branch and on develop branch
2. Open a system monitor and observe the memory usage

Screenshots

See screenshots inline above ^

Example code

It does not really matter what code is being used. The demo reproduces the same problem.

Fyne version

4c67d93

Go compiler version

1.18.7

Operating system

Linux

Operating system version

Fedora 36

Additional Information

No response

[andydotxyz]

Is the same increase shown in smaller or larger apps? Does it seem to be universally 2* or is it closer to 27MB higher for each app?

[Jacalz]

I launched the cmd/hello executables and it seems as there is an initial 1.4x increase, or a 9MB increase in this case.

Clicking the button did not change much in terms of memory usage.

[Bluebugs]

You could look using sudo pmaps FYNE_DEMO_PID if the problem isn't just an increase in shared library usage which in that case doesn't really count for much as they will be shared. Measuring real memory usage of a process on Linux is fun :-)

As for the go memory allocated for sure, for fyne_demo and hello, a big culprit is vendor/github.com/benoitkugler/textlayout/fonts/glyphsnames/glyphs.go which allocate a lot of memory at startup as it use a map which is not read only/doesn't give a chance to the OS to do an optimistic load on it (10% of the allocated memory usage).

The second that I do not understand why, but we do allocate and keep allocated a single big *image.Alpha at all time (25% of the allocated memory usage). I would guess it is not necessary to keep it around, but not sure how we can make it better. I think that as we render things in opengl, it would be good to actually have the memory provided by the painter (to avoid unecessary copy and use of things like a single GL buffer)

[andydotxyz]

With the last two improvements to font memory usage can this be closed @Jacalz?

[Jacalz]

I don't know. For some reason I am seeing more memory usage on develop now than on the release branch for v2.3.x. We are still over double to v2.2.4. Will have to check my workstation when I get home and see if I get similar results there. It seems unexpected given that I saw decreases with both of the PRs that you mention.

[andydotxyz]

That is very strange.
Maybe something slipped in that was not measured. Possibly the removing race condition from images, as that now caches the pixels on the image object?...

[Bluebugs]

I am guessing @Jacalz is not using go pprof tools for benchmarking memory consumption, but using linux top or some equivalent tool. This might be also affected by kernel, cpu and general environment. So comparing between machine on those number is hard.

[Jacalz]

I was indeed not comparing using pprof but I also wasn't comparing between two machines. Will look into this more

[andydotxyz]

This is marked as a blocker, does it need to hold back v2.4.0 at this stage?

[Jacalz]

Nah. I am still seeing the same amount of memory usage but it shouldn't need to hold back the release.