Login into Plasma (from when press "login" button in sddm until plasmashell panel appears) takes me 1 minute 26 seconds! That's ridiculously slow. I tried to analyze what's going on, and concluded that it's related to heavy disk I/O that's happening during login. I'm using an HDD which is reasonably fast in general (WD Black 2TB) and main filesystem is XFS. It performs within expected norm in various benchmarks. Checking what's going on during login, I noticed that mysqld and akonadiserver take quite a lot of I/O, potentially choking plasmashell and preventing normal desktop elements from come up sooner (and even some windows from the previous session like Konsole come up before plasmashell does). I suppose KDE shouldn't be oriented just to SSDs which allow massive parallel access, but should perform resonantly well on HDDs too. While I'm planning to get an SDD, Plasma should be able to handle this better and it's not a proper solution here. May be login process should prioritize plasmashell and postpone other heavyweights like akonadiserver, mysqld and what not, in order for the overall shell UI to become functional instead of presenting an unloaded desktop? And 86 seconds until functional desktop - that's just terrible.
For the reference, after logging out, and logging back in, it's almost instant, which again suggests that it's I/O related issue, because on second login a lot is already in filesystem cache. I even tested that explicitly by loging out, purging filesystem cache from tty with echo 3 > /proc/sys/vm/drop_caches And logging was again slow.
Thanks We're constantly trying to reduce our startup time both in IO and everywhere else. There are multiple improvements this cycle and more planned. Unfortuantely as a bug report this isn't very useful; there's no definitive single issue, nor on a single product as such it's never closable. If you can identify a specific point of something being loaded needlessly or multiple times, please do file a new bug report.
(In reply to David Edmundson from comment #2) > > If you can identify a specific point of something being loaded needlessly or > multiple times, please do file a new bug report. OK, I can make it more narrow. For example refactor startup procedure to give plasmashell more priority.
It does have more priority. It's in autostart phase 0. The rest comes after, so done.
(In reply to David Edmundson from comment #4) > It does have more priority. It's in autostart phase 0. The rest comes after, > so done. Well the problem is still here. Current login time is atrocious on HDD, If you say that plasmashell has higher priority already, how is that mysqld and akondiserver kick in before plasmashell is fully loaded? Something doesn't fit here.
(In reply to David Edmundson from comment #4) > It does have more priority. It's in autostart phase 0. The rest comes after, > so done. I hope you understood what I'm trying to say. I want to see desktop to load before heavy I/O starts slowing everything down. If you think the bug should be rephrased some other way to address that, please advise.
You are probably using the Plasma calender with KDEPIM integration. That needs akonadi, which in turn needs mysql. I suggest to disable the Plasma KDEPIM integration. Please ask in a forum of your distribution if they offer separate packages for that (openSUSE, for example, does).
(In reply to Christoph Feck from comment #7) > You are probably using the Plasma calender with KDEPIM integration. That > needs akonadi, which in turn needs mysql. I suggest to disable the Plasma > KDEPIM integration. Please ask in a forum of your distribution if they offer > separate packages for that (openSUSE, for example, does). I'm using Kmail. Disabling it helps only slightly. The problem is there by design. Any I/O heavy process that kicks in on startup chokes plasmashell. Like for example starting Firefox which reads its cache and other data. It's the design that needs some change IMHO. I.e. plasmashell should load fully before any intense I/O slows it down. I understand that on SSD this is not an issue, and you on the contrary want everything to start right away, to reduce log-in time. On HDD, to reduce that time different startup strategy is needed, not wild west race for I/O resources. May be Plasma can determine, whether HDD or SSD is used, and apply needed strategy accordingly.
Or you are saying that with calendar integration plasmashell can't complete loading its UI before akonadiserver and mysqld finish starting? Then I suppose it also requires some approach redesign, that UI should appear partially, and update missing stuff as it loads, instead of stalling the whole UI waiting for I/O heavy stuff to complete.
If you can confirm that starting akonadi from within the plasmashell startup blocks the process until it is started, then yes. I do not have akonadi installed to verify.
Created attachment 109907 [details] Script to be used as autorun
Created attachment 109908 [details] Script with the apps that must be loaded on every initialization
OK, don't know if will be useful to analyze the delays on init but I use a workaround for it that gives me normal startup every time will all applications I would otherwise use without the trick. First, I block on "Settings / Startup and Shutdown / Desktop session" all applications I would otherwise autostart or that KDE would open from previous session. Second, I register on a empty "Settings / Startup and Shutdown / Autostart" only one shell script. I use 2 scripts to complete the required tasks, both are attached. Finally, I restart KDE. My guess, and I pretty well may be totally wrong as I did not look on the initialization code, is that the parallelism is, somehow, inducing a lots of timeouts and as so resulting on lots of reread requests which end up slowing all things. What the scripts do is invoke konsole from bash, start many things in background and then request a read with 1 s timeout. I suppose, and it is another wild guess, that the important aspect of it is that KDE support libraries must be ready so that konsole can be shown and the shell accept IO, somehow thwarting the race condition a bit. May it be true (emphasis: I have not idea if it is), perhaps, forcing the GUI to be ready before launching applications would fix the issues we have. Regards and best wishes to all.
Forgot to add. Another possibility is that applications may try to start to system tray and all the required services it gives may not be ready yet, so, some timeout and requests repetitions may come to play again. This seems to affect goldendict and zeal at startup. May you all forgive all guessing if none of them further progress.