- This topic has 5 replies, 4 voices, and was last updated Oct 11-1:25 am by Brian Masinick.
-
Posts
-
anti-ewaste
I’ve seen this mention in passing, and I just installed 19.2 on an old Core2Quad (love that it costs 6% of original retail) and was just curious about this. I’m just wondering from a practical user point of view just how much bloat it adds. In looking it up I was introduced to the concept of mission creep which was interesting..
Brian Masinick
I think that systemd has a few binary images and it also promotes the use of multiple processes taking place at the same time during start up and in scheduling tasks.
The concept is worthwhile, the specific implementation is the typical concern.
As far as additional overhead it’s not that easy to isolate without looking at the exact images that run. I’d simply say that it’s a trade-off between a binary implementation (in executable code) versus an image that forks multiple processes that are triggered by configuration settings, scripted code and kernel scheduling.
I’ve not seen studies yet on the size, but I have seen plenty about the choice of the approach and WHO wrote most of the code. It’s more a choice of approach and principle in my opinion than a big difference in size or speed.
Pressed for an answer, I would SPECULATE that systemd startup can be slightly faster on fast systems with a lot of resources and many processors with a cost of slightly more memory used.
With only a few processors available on limited memory I doubt that there is any advantage, perhaps an overhead. On most systems that are 5 years old or less with ample resources there’s a possibility of a faster startup though it’s not a big difference.
All speculation, I’ve not recently read any definitive reports about it either way.
--
Brian MasinickAnonymous
wondering from a practical user point of view just how much bloat it adds
I’ll recommend this websearch query: “systemd memory overhead”
In your reading I expect you’ll discover that the “journald” component can be (depending on configurable system settings) problematic as a “memory hog”, but the remainder of the the systemd stack is unremarkable, from “a practical user point of view”.
Brian Masinick
Skidoo’s comments – and the available discussions – pretty much echo what I’ve suspected:
Yes, there can be overhead with systemd, but with the exception of a defect, which is triggered by a server workload (not a user workload on a personal system, the differences in memory usage are slight, so the research I just read confirms what I was speculating – that there can be some overhead, but the trade-off is essentially slightly faster startup (and maybe a very slight improvement in process handling on a well-configured system) at a cost of a moderate increase in memory consumption – but to me, in the systems I regularly use, the difference is barely perceptible.
I use Debian, MX Linux, antiX, KDE Neon, openSUSE, right now, occasionally running others; Fedora is often there in place of Neon – and in this grouping, some are systemd-based, others use sysvinit or something else – one antiX uses runit – there are only slight differences; more notable are the applications I run at any given time. Those can have a much more noticeable impact on memory and overall performance.
--
Brian Masinicksemicynic
Here is a pretty good comparison of sizes of code for systemd compared to sysVinit; I was amazed at the disparity.
“Why Linux’s systemd Is Still Divisive After All These Years” by Dave McKay on “www.howtogeek.com”
I took excerpts from this and from comments on distrowatch.com but it wasn’t published there.
McKay’s article is definitely worth reading by any antiX user.
Brian Masinick
- You must be logged in to reply to this topic.
