Slow opening applications...

English Applications
1

When opening applications the system grinds to a halt. Mouse movement is very jerky and keyboard response is slow. The system returns to ‘normal’ after the applications have completed opening. This behavior is really bad when opening Firefox or Chrome. I noticed that both of these applications in particular are memory hogs, especially if you leave them open for long periods of time.

My system is an ASUS K53E with 4GB RAM.

This was first noticed after installing Tumbleweed. I figured it would improve over time, but it has not. Is there something I can do to improve performance?

2

I mostly use Leap 15.1, so I don’t much notice this.

On Tumbleweed: yes, things are slow starting. I’m not sure why. For example, I boot Tumbleweed, then “su” to root in an “xterm”. That’s all fast enough. And then I run “zypper dup” to update. And it just sits there doing nothing for a minute or three. After that delay, it begins to refresh repos. But something is delaying the start of that.

It is possibly some sort of lock. The load average does not drop below 1 until we have passed that initial delay.

Once that delay period is passed, all seems to be normal.

3

Running Tumbleweed on a not particularly beefy system.
2.4 Ghz multicore with slightly more RAM.

No delays with zypper and apps start immediately.
When I’ve had delays with zypper starting I’ve always associated them with temporary connection issues.
One thing that does seem to have had a bigger impact on performance than I would have expected is an SSD.
That reduced delays noticeably when multitasking.

4

I completely agree, using a SSD makes such a difference.

5

SSD is always a worthwhile investment. For safety I recommend frequent backups to external storage.

To make a slow openSUSE faster, keep only installed what is absolutely needed, and ditch the rest. Then incrementally add those nice-to-have things one by one and run your system for a day or two with that one addition. That way you can identify anything slowing down your system much easier.

Here’s a few things I do:
[ul]
[li]Disable IPv6 — there is still some networking gear out there that works best with IPv4 only.
[/li][li]Disable fast file search/content indexing like baloo or locate; instead, use alternatives like find that don’t maintain a custom database.
[/li][li]Remove eye candy like Plymouth or SDDM (in my tests, unthemed KDM was the fastest display manager for starting up KDE/Plasma; GDM may be just it for Gnome).
[/li][li]Switch off any GUI animations and 3D/composer/Compiz effects that might slow down your graphics environment; also: disable the KDE splash screen.
[/li][li]On SSD-based systems, make sure that your partitions are aligned correctly; re-partition (I use one primary ext4 partition only, with GRUB in the MBR) and re-install.
[/li][li]If at all possible, avoid btrfs (you may not ever use its advanced features like snapshots anyway). There have been many occurances where btrfs scrubbing & balancing tasks slowed down the system where ext4 would not; same with btrfs COW, soft-raid, subvolume stuff that is not well-suited for everything.
[/li][li]Disable and mask any automated services you could as well invoke manually:
[/li][LIST]
[li][]fstrim (as a habit I invoke it manually once every month after my backups are done)
[/li][li][]smartd (see fstrim)
[/li][li][]backup-rpmdb (unneeded)
[/li][li][]Plymouth (worth mentioning again)
[/li][li][]ntpd or chrony (my mainboard/BIOS/hw clock happens to run with excellent accuracy, no need for time servers)
[/li][li][]wicked (can lead to really slow network initialization, try systemd-networkd for statically reserved IPv4, or NetworkManager for anything dynamic/DHCP/Wifi etc)
[/li][li][]postfix (install exim, if you need local mail processing at all; otherwise, disable and mask both with systemctl)
[/li][li]
[/li][/ul]
[li]Disable any KDE (or Gnome) components you don’t need (for KDE, which I use, this would be in System Settings → Startup and Shutdown → Background Services):
[/li][ul]
[li][]Drive Ejector
[/li][li][]Free Space Notifier
[/li][li][]KSysGuard
[/li][li][]KDE Network stuff (leave that to the kernel)
[/li][li][]Remote URL Change Notifier
[/li][li][]Touchpad
[/li][li][]Baloo (worth mentioning twice)
[/li][li][]any automated KDE-PIM stuff like Akonadi
[/li][li]
[/li][/ul]
[li]Keep a list of all services, packages and other stuff you disabled, uninstalled, marked »taboo« in YaST or masked with systemctl — that way, you can reproduce your installation and reason about its dependencies more easily:
[/li][ul]
[li][]If you mark as »taboo« every package YaST installed and you then uninstalled, you can generate a list with »zypper ll > taboo.text« (my zypper currently lists 357 locked packages).
[/li][li][]If you stop/disable/mask services with YaST or systemctl, make screenshots, keep the command history (.bash_history) archived, or log it like »systemctl --state=masked« (I masked 19 unneeded units).
[/li][/ul]
[li]Finally, a few dracut-related things I do in order to keep my early boot phase quick and efficient. After every manual change that might influence the contents of the initrd (initial RAM-disk), re-build it with dracut — specifically, you can use dracut to help your system boot faster and leaner:
[/li][ul]
[li][]On my SSD-based system, an uncompressed initrd loads faster than for the kernel to unpack a compressed initrd (I use »dracut --hostonly --force --no-compress«). Best to benchmark any changes with »systemd-analyze«.
[/li][li][]Make explicit that you always boot from local HDD/SDD, and that dracut won’t search any optical/remote/crypto/network storage for bootable volumes (see kernel parameters »rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0« and command options like »dracut --omit “img-lib cifs fcoe fcoe-uefi rdma multipath iscsi qemu lvm mdraid dm dmraid pollcdrom plymouth btrfs”«; warning: your mileage may vary)
[/li][li][]When you found a dracut invocation that is minimal and boots your system good and fast, make it permanent in /etc/dracut.conf.d/ so YaST uses it with every kernel/systemd/dracut/driver update
[/li][li]
[/li][/ul]
[/LIST]

I’ve posted some more detailed stuff about optimizing system bootup and contents of the dracut-generated initrd here.

Cheers!

6

Never observed any delays with Tumbleweed starting applications:

erlangen:~ # time zypper dup --allow-vendor-change --auto-agree-with-licenses  --allow-downgrade 
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...

Nothing to do.

real    0m1.619s
user    0m0.524s
sys     0m0.146s
erlangen:~ #
7

Maybe one of those update-notifier widgets is the culprit for slow program launches shortly after booting/wakeup/unsuspend.

@GeoK6868 (OP) — I remember the widget that came preinstalled with KDE/Plasma did that. I imagine it did something like »zypper refresh« and »zypper lu« under the hood, then popped up a notification about any available updates in the KDE taskbar on the desktop.

I don’t know about Gnome, but maybe a system with KDE and 4GB RAM does get a bit choppy, having zypper update its repos, maybe Baloo or locate doing their background indexing thing while starting a complex user application like, say, Steam or Thunderbird which themselves cause network traffic and subsequent loading of uncounted libraries and other files. If that’s the case, maybe ditching those desktop widgets/gadgets/meters/notifiers may help a bit. Also, switching off KDE/Gnome sound effects, app-starting animations and avoiding large images as desktop backgrounds (it all can add up). With KDE, having ksysguard open and observing its »Process Table« and »System Load« tabs while launching the app may reveal some bottlenecks.

If command line tools behave fine and only graphical apps make the system feel sluggish, maybe it’s the graphics driver. Make sure the system uses hardware acceleration and not the slow software emulation (Mesa-something or fb — a framebuffer? Both can be super slow). Especially on Laptops, you sometimes have to deal with dual-GPU setups (one for saving power while on battery, the other chip for graphics-intensive stuff). I don’t have any experience with those, but they are a regular topic in Linux forums.

What I’ve completely forgot in my lengthy list is checking enough disk space is available and whether Linux has to use the swap partition a lot:

rig:~ ▶ **df -hT**
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  3.9G     0  3.9G   0% /dev
tmpfs          tmpfs     3.9G  4.1M  3.9G   1% /dev/shm
tmpfs          tmpfs     3.9G  1.2M  3.9G   1% /run
tmpfs          tmpfs     3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sda1      ext4      230G  135G   94G  59% / 
tmpfs          tmpfs     791M   12K  791M   1% /run/user/1000
rig:~ ▶ **swapon --summary**
# well, I don’t have a swap partition, but this would list some statistics — ideally, the swap partition never sees any I/O.

A final thing to keep in mind: if the fan in the laptop is old or clogged with dust, the hardware may overheat and reduce clock frequencies of CPU and/or GPU which, in turn, slows down the software. Maybe installing the »lm-sensors« package will give you more info about internal temperatures and fan rotation speed.
Cheers!