Memory Footprint Reduction

1 view
Skip to first unread message

Gordan Bobic

unread,
Aug 18, 2019, 9:42:06 AM8/18/19
to redsleeve-users
A thread on this subject came up over on Fedora devel list, so I thought it would be of interest here as well. The important part is in this link:
https://wiki.wxwidgets.org/Reducing_Executable_Size

Jacco, how do you feel about changing the default build flag options in rpm macros and having a go at this? Can you think of anything that might break? If not, I'm vaguely tempted to spin up an experimental build by pushing all of our srpms through the rebuild process.

There's bound to be something that will decide to segfault because of a bug that somehow remains undisturbed by the upstream defaults, but it could be really handy if it gets anywhere near halving the memory footprint of RS.

Jacco Ligthart

unread,
Aug 19, 2019, 3:04:11 PM8/19/19
to redslee...@googlegroups.com

Hi Gordan,


Although I like the idea, I'm not tempted to do this on a release scale. A couple of reasons:

- like you said, there *will* be strange bugs/segfaults

- probably a whole release will not be easy. I expect a fair amount of packages to fail building. I often encounter packages that don't build on release 7.x while they do build on 7.x-1

- I like that many/most/all? packages that build also work, without much testing.

- TIME. I got most of 7.7 build as well as 8.0. Both waiting on CentOS to release, so I can leech their packages and repo layout. When that happens, I got enough work on my plate ...


Jacco

--
You received this message because you are subscribed to the Google Groups "redsleeve-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redsleeve-use...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/redsleeve-users/CAMx4oe0B2XmB7L5TkTx22XZufGomMhyP2tH%3Dmn7XixN13yz9gw%40mail.gmail.com.

Gordan Bobic

unread,
Aug 19, 2019, 3:13:03 PM8/19/19
to Jacco Ligthart, redsleeve-users
I'm going to try it at least with the biggest of the memory hogs, such as KDE, Gnome, Firefox, Libre office, and glibc (latter mainly because a saving there will impact everything).


Reply all
Reply to author
Forward
0 new messages