The Appcenter currently performs its background tasks within the same process that is used for its GUI, so once you browse it for some time, you'll have an extra 100MiB of GTK theme data, hidden windows, icons, screenshots and such wasting your RAM until the system is restarted. This also denies the user an ability to reset the Appcenter app by simply closing and reopening it, in case it becomes unusable.
While a 100MiB doesn't seem like much, the cruft adds up, and Juno now requires 700MiB at all time compared to Loki's 400MiB. With modern laptops and office PCs generally having 4GiB or RAM this is hardly acceptable. Moreover, Linux tends to freeze once the RAM is exhausted, so it's a precious resource.
I believe I can refactor the background tasks into a separate daemon, communicating with the frontend via DBus, and having an estimated footprint of less than 10MiB (as measured by the smem tool's PSS field). I only need a go-ahead from someone on the team to get working.
BachoSeven
commented
6 months ago
The Appcenter currently performs its background tasks within the same process that is used for its GUI, so once you browse it for some time, you'll have an extra 100MiB of GTK theme data, hidden windows, icons, screenshots and such wasting your RAM until the system is restarted. This also denies the user an ability to reset the Appcenter app by simply closing and reopening it, in case it becomes unusable.
While a 100MiB doesn't seem like much, the cruft adds up, and Juno now requires 700MiB at all time compared to Loki's 400MiB. With modern laptops and office PCs generally having 4GiB or RAM this is hardly acceptable. Moreover, Linux tends to freeze once the RAM is exhausted, so it's a precious resource.
I believe I can refactor the background tasks into a separate daemon, communicating with the frontend via DBus, and having an estimated footprint of less than 10MiB (as measured by the
smemtool's PSS field). I only need a go-ahead from someone on the team to get working.