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

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 19 installer memory usage

Fedora 20 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!

10 Responses

  1. piruthiviraj
    piruthiviraj November 28, 2013 at 7:03 pm | | Reply

    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.

  2. Xyzzy
    Xyzzy November 28, 2013 at 8:46 pm | | Reply

    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

  3. Gabriel M. Elder
    Gabriel M. Elder November 30, 2013 at 6:58 am | | Reply

    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.

  4. Herman
    Herman November 30, 2013 at 8:44 am | | Reply

    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.

  5. Harald Hoyer
    Harald Hoyer December 2, 2013 at 12:57 am | | Reply

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

  6. Andreas Nilsson
    Andreas Nilsson December 2, 2013 at 4:28 am | | Reply

    piruthiviraj: It would probably be better to fix the performance issues in GNOME than to replace the entire UX.

    Adam: Thanks for the numbers!

  7. Pádraig Brady
    Pádraig Brady December 2, 2013 at 4:49 pm | | Reply

    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.

  8. Samuel Sieb
    Samuel Sieb December 3, 2013 at 10:50 am | | Reply

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *