Some comparisons between Fedora 13, 15, 17, 19 and 20

Adam Williamson

2013-11-28 17:43

It's all a bit quiet around Fedoraland today with U.S. Thanksgiving happening. So I took some hours out today to do some comparisons of a few key things between a bunch of Fedora releases: 13, 15, 17, 19 and 20. Let's take a look at the numbers, Jim! All the raw data is available here. For every release, I used the same KVM VM (specced with 2 CPUs and 2GB of RAM), running on a Fedora 20 host. For Fedora 13 I used cirrus graphics with VNC (the old default), as it cannot handle qxl/SPICE; for all the others I used qxl/SPICE. I did an install using all default choices from the DVD image. Fedora 20 used Final TC3, all others were Final releases.

'free'-reported memory in use from console after boot to runlevel 3

Fedora 13: 129948 Fedora 15: 144788 Fedora 17: 119616 Fedora 19: 153644 Fedora 20: 148720

'free'-reported memory in use from GNOME terminal after boot to runlevel 5, create user, log in

Fedora 13 (GNOME 2): 276104 Fedora 15 (GNOME 3 fallback): 297680 Fedora 17: 389672 Fedora 19: 534376 Fedora 20: 691872 We can see that the memory used when you simply boot to a console and log in has changed very little all the way back to Fedora 13, released 2010-05-25. We're doing a fairly good job of keeping our base system from bloating excessively. 19 and 20 are both 30MB worse than 17, but then, 17 was 25MB better than 15. UPDATE 2013-12-03: Note regarding the following section about GNOME's memory use: the situation may be more complex than it seems. Testing on bare metal does not produce the same results as testing in a VM, and the use of llvmpipe-based software rendering in the VM may be throwing the numbers off; it's possible F20 isn't significantly worse than F19 in this respect after all. See this post. The same certainly doesn't hold true for the graphical desktop, though. Just sitting at a mostly-idle desktop with a terminal open, our memory usage has gone from 275MB under the ancien GNOME 2 regime to 300MB with GNOME 3's 'fallback mode' (which was more or less GNOME 2), then rocketed to nearly 400MB, 535MB, and nearly 700MB in subsequent releases. I haven't yet looked in detail at the changes, but I did take screenshots of 'top' ordered by memory usage for each install. Fedora 13: Xorg 24M, gnote 21M, python 19M, nautilus 17M, gnome-panel 16M, clock-applet 15M, wmck-applet 13M... Fedora 15: Xorg 53M, systemd 22M, gnome-settings-daemon 18M, clock-applet 15M, gnome-panel 15M, gnome-session 14M, gnome-terminal 14M, wnck-applet 12M... Fedora 17: gnome-shell 115M, Xorg 53M, systemd 24M, gnome-settings-daemon 21M, gjs-console 19M, gnome-terminal 17M, tracker-store 16M, libsocialweb-something 16M, goa-daemon 15M, nm-applet 14M... Fedora 19: gnome-shell 160M, Xorg 26M, evolution-data-server 26M/25M/23M/22M (4 processes), gnome-settings-daemon 22M, goa-daemon 22M, gnome-shell 20M, firewalld 20M, libvirtd 18M, gnome-terminal 18M, tracker-store 17M... Fedora 20: gnome-shell 328M(!), evolution-data-server 56M/28M/22M (3 processes), gnome-settings-daemon 30M, Xorg 26M, systemd-journald 22M, gnome-shell 21M, firewalld 21M, goa-daemon 20M, gnome-terminal 19M, libvirtd 19M, tracker-store 17M... these are all the raw 'RES' numbers, which don't really tell the whole story, but they're close enough for a ballpark. The obvious things that jump out are that we don't really see the memory usage of particular elements of the desktop increasing over time - where the same processes occur in multiple releases, memory usage is usually pretty similar - but GNOME seems to be running more and more stuff by default over time (there's a couple of new basesystem bits too, but we can tell from the runlevel 3 numbers that the net impact there is small), some of it adding significantly to the memory burden. GNOME 3 is also clearly heavier than GNOME 2. The obvious big exception is that the memory usage of the Shell itself grew massively - in fact, more than doubled - from Fedora 19 to Fedora 20, accounting for all the overall increase in memory usage from 19 to 20 by itself. gnome-settings-daemon has also been growing on a more modest scale, from 18MB at F15 to 30MB in F20. I don't know if anyone in GNOME land is focused on efficiency, but these numbers suggest that it might be a good idea to spend some time on it. Some of the increase is probably unavoidable with GNOME's increase in capabilities over time, but some of it is probably fixable.

Size of installed system

Fedora 13: 3GB Fedora 15: 3.1GB Fedora 17: 3.5GB Fedora 19: 3.4GB Fedora 20: 3.5GB Well, nothing much interesting going on there.

Loaded services at runlevel 3

Fedora 15: 56 Fedora 17: 42 Fedora 19: 38 Fedora 20: 47 Seems like we were gradually reducing the number of services loaded at boot from 15 through 19, then reversed course for 20. This is one where the raw numbers are a blunt instrument, though, and you have to look at details. Manually comparing the 19 and 20 lists doesn't reveal any huge oddities; it's mostly just that more things which were happening at startup anyway appear as discrete systemd units now. One that does seem a little odd is that 19 did not have ModemManager.service running by default, but 20 does.

Package set

It's kinda fun to diff the default package set from release to release; I saved a full list of packages installed (without versions) in each release. Fedora 13: 1204 packages Fedora 15: 1204 packages Fedora 17: 1209 packages Fedora 19: 1237 packages Fedora 20: 1309 packages There's a lot of detail in there, of course. For fun, here is a diff between the Fedora 13 and Fedora 20 package sets. A bit more usefully, here is a diff between the Fedora 19 and Fedora 20 package sets. The additions in 20 look to be kinda split between new functionality and added deps for existing things.

Kernel size

Fedora 13: kernel 3.5MB, initramfs 123MB Fedora 15: kernel 3.9MB, initramfs 147MB Fedora 17: kernel 4.7MB, initramfs 174MB Fedora 19: kernel 5.1MB, initramfs (generic) 266MB, initramfs (stripped) 118MB Fedora 20: kernel 5.1MB, initramfs (generic) 376MB, initramfs (stripped) 121MB In F18 or F19 (I forget which) we stopped using a generic initramfs - one with every possible thing in it - by default, and started stripping the initramfs to contain only stuff needed for the installed system. We install a 'rescue' initramfs (and boot menu entry) which is generic at install time, so if you change your system's hardware in a way that the stripped initramfs can't cope with, you have something to boot from to generate a new stripped initramfs. That's what the "generic" and "stripped" numbers are. As we can see, the kernel+initramfs have sure gotten bigger over time; I'm not qualified to speculate on how much is additional capability and how much is bloat, but it might have been nice to compare an 'lsinitrd' for each release (unfortunately, I didn't think to save one). The 'stripped' initramfs plan was a bit controversial, but these numbers at least illustrate that it certainly serves a need. Remember, the initramfs is loaded into memory at boot time, so these numbers translate directly into unavoidable memory consumption for the booted system. It's interesting that F20's generic (rescue) initramfs is so much larger than F19's.

Boot speed

Only have numbers for 19 and 20 here, as systemd's handy-dandy 'analyze' capability didn't exist for 17 and earlier, and I wasn't going to bother manually doing bootchart. Fedora 19: 16.720s (console), 18.809s (graphical) Fedora 20: 14.977s (console), 17.571s (graphical) Fedora 19 console bootchart Fedora 20 console bootchart 20 got a second or so faster than 19, which is nice. Both are pretty snappy. Of course, I'm running on a host with lots of RAM. The guest disk images are stored on my fairly fast NAS.

Installer memory consumption

For 17, 19 and 20 I ran the installer memory profiler that Chris Lumens wrote and I blogged about before. Here are the charts. Fedora 17 installer memory usage

Fedora 17 raw memory usage data Fedora 19 raw memory usage data Fedora 20 raw memory usage data The broad shapes of each graph are very similar; it's obvious that there haven't been really major changes in the way the installer uses memory between these releases. We did kill the thing that generated the huge peaks early in install in Fedora 17 (it was an SELinux policy thing, IIRC). The later peaks in all three graphs are packages running gtk-update-icon-cache and update-mime-database in their %post or %posttrans. It's somewhat interesting that the peaks seem to flatten out at the tops in the F20 graph, but I don't know yet what's behind that exactly. Fedora 20 is slightly heavier on memory usage than F19 was overall. There is no obvious smoking gun behind this, though - as noted, the overall shapes of the graphs are very similar. Fedora 19's installer initramfs is 328MB, Fedora 20's is 343MB; this probably accounts for 15MB of the difference. The absolute peak usage for Fedora 19 is 704156 (704MB) during the last gtk-update-icon-cache run (the previous one hits 703780), for Fedora 20 is 775364 (775MB) during the second-to-last gtk-update-icon-cache run (the last hits 761724). Right after the final gtk-update-icon-cache run, and before the gradual ramp-up in usage that happens during yum's 'verification' step, F19 is at 583MB, F20 is at 642MB. So that's about 60MB, minus the 15MB initramfs, that's gone somewhere between 19 and 20. So...there's a bunch of data, I guess. =) Hope it was interesting!

Comments

piruthiviraj wrote on 2013-11-29 03:03:

Since Gnome-shell turning into big memory monster why can't Fedora shift to a lightweight DE as default like XFCE and still provide gnome as spins? Debian already has plans for it.

Xyzzy wrote on 2013-11-29 04:46:

I definitely agree about it being a good idea for the GNOME 3 team to focus a bit on efficiency. It would be interesting to see similar information on a KDE 4 install over the years for comparison. KDE runs just fine on my ancient** laptop, but I get the sense GNOME 3 wouldn't. **IBM Thinkpad T43: single-core Centrino 2.0GHz, currently 1GB of RAM

adamw wrote on 2013-11-29 08:15:

xyzzy: I had the same thought, and I might try and run the same comparison for KDE if I can find the time over the weekend. I expect Xfce and LXDE would not change much over the same period - simply because those desktops themselves really haven't changed much.

adamw wrote on 2013-11-29 08:17:

xyzzy: in practical day-to-day use, though, it's worth noting that in my experience, the web browser is usually #1 RAM user on any given system. Right now, on my system, Firefox is taking up somewhere north of 1GB on its own. All modern web browsers seem incredibly hungry. It's difficult to run even LXDE or Xfce on a 1GB system if you want to use Firefox or Chrome as a browser, and I suspect web use is a big reason phones feel much better with 2GB of RAM than 1GB.

Gabriel M. Elder wrote on 2013-11-30 14:58:

Thank you for taking the time to do this. I'm a huge fan of efficiency and anti-bloat, especially in the free software community. Glad to see you putting a spotlight on this, especially in regards to gnome. I've grown accustomed to the gnome-shell ui and like it a lot, but there are plenty of older, yet reasonably powerful machines I've encountered on which I have to run LXDE (my lightweight UI of choice) instead. As a quick aside, I have noticed since f19 (f20 seems to have this too, when I ran the beta) that the upper-left hot corner in the gnome-shell ui is intermittently 'hot', only responding to the mouse placement up there and properly switching to the applications overview about %60 of the time. Not sure what's up with that, but it's really kinda stupid and annoying.

Herman wrote on 2013-11-30 16:44:

Gabriel M: The behaviour of the upper left corner has changed, you now have to position the mouse cursor there and than push it up and left a little farther still, as if you were trying to push it beyond the edge of the screen. I guess they did this because users complained the overview screen popped up by accident too much.

Harald Hoyer wrote on 2013-12-02 08:57:

The initramfs memory should be freed after the switch-root, so it does not contribute to the stage2 of the installation.

Andreas Nilsson wrote on 2013-12-02 12:28:

piruthiviraj: It would probably be better to fix the performance issues in GNOME than to replace the entire UX. Adam: Thanks for the numbers!

Pádraig Brady wrote on 2013-12-03 00:49:

Thanks for doing this. Re memory consumption, the total increase is very interesting. For getting possibly more accurate per program reporting taking sharing into a/c etc. have a look at ps_mem tool which is in Fedora >= 20, but you can install it on any Fedora as it's a simple python script.

Samuel Sieb wrote on 2013-12-03 18:50:

Continuing from what Harald said, on a normal boot the initramfs should be freed once the main system is started. The difference between the rescue and minimal initramfs is the time needed to read it off the disk and probably fewer things running during the initial boot sequence.