Around 20 sec plasma start on i7-920/12GB/Crucial M4 128GB SSD. Same with clean new profile.

*** This bug has been confirmed by popular vote. ***

Could be related to D-Bus message passing.

Hello, Christoph!
Any ideas how to fix it?

It is possible that Plasma waits for Akonadi to start. Could you disable Akonadi use in Plasma and check if it fixes the wait? See http://www.google.com/search?q=disable+akonadi+plasma

akonadi not installed 
cat ~/.config/akonadi/akonadiserverrc:
...
StartServer=false

akonadi not installed 
cat ~/.config/akonadi/akonadiserverrc:
...
StartServer=false

I also experience the same issue with akonadi server disabled.

I was considering opening a "general KDE bug" for the slow startup time experienced (I suppose this fits best under KWin?). I mean, after I login, the computer can be useless for several minutes, compared to three seconds or so using e.g. E17. Unless this is my fault for configuring it wrong, I believe this is a major issue. I have no idea what is taking time, I suppose Akonadi, Plasma and more components are partly at fault. It is very present and very unimpressive for the end user.

I apologize if I am too harsh with my wording. I am only annoyed because I appreciate all the brilliant design ideas that goes into KDE and I very much appreciate all your hard work of course! I believe that instead of developing many new features (which is perhaps more fun for developers?), there should be a higher focus on polishing the core product into an absolute masterpiece ;)

About my setup: Macbook Pro 5. gen, Arch Linux running KDE 4.7.2.

I just ran the three steps suggested in the first comment. Starting plasma-desktop takes 40 (!) seconds on my machine. After that it still takes about 10 seconds before things start feeling responsive. Perhaps I have some particularly slow widgets installed? C2D 2.4 GHz, 4 GB ram.

40 seconds of disk activity? Or does it block somewhere?

I found similar problems after upgrading to 4.7, up to 4.6.5 everything was fine (and still it is, I downgraded and verified it). I did a long investigation and, at least in my case, I think it is due to having the root partition on an ext3 filesystem. See:

https://bugs.kde.org/show_bug.cgi?id=282704

and links therein. I don't know if this is really the cause of the problem for everybody experiencing it, but I hope my experience could be useful to find a soution.

@Christoph Sorry for answering so late. I am unsure, how can I check that? I don't get the impression that the computer is under heavy load (cpu fan is normal etc), so my initial guess would be some blocking.

@Nicola Hmm, I am also using ext3, and I don't currently have the time to reinstall. I will make sure to use ext4 next time.

@Yngve And I'm on Archlinux too. But also OpenSUSE users have reported such a problem, and I personally verified that it exists also on Kubuntu 11.10. It is interesting that you too have an ext3 filesystem... The only working workaround that I found is to mount /var/tmp as tmpfs (I know it is not recommended): doing so, everything is as fast as one might expect, so in my opinion there's a process which is very inefficient when writing on /var/tmp on an ext3 disk. This process has been introduced in 4.7 since 4.6.5 works fine.
This is everything I have been able to understand...

@Nicola Well, you've understood quite a bit more than me.

Was it in 4.7 that Akonadi was turned on by default? Could that make a difference? I tried to turn it off by setting StartServer to false in .config/akonadi/akonadiserverrc, but I did not see any significant changes. I should add that startup time fluctuates quite a lot, so it is difficult to measure precisely. I've measured the time from I hit enter after giving my password, to when it tells me yakuake is started (which I have autoloaded on startup). That time fluctuated from more than 3 minutes, and down to about 1m15s. It looked like the time decreased after successive startups, which is perhaps to be expected? I don't know much about these kind of issues...

I also noted, that if I log out and log in again, it takes less than 20 seconds for the desktop to load, so it is most probably something that is only done during "initial startup".

I've removed pretty much all plasmoids, keeping only one folder view. I only have one workspace. If people have suggestions to other stuff I could try to turn off, please let me know.

One random idea. The clock widget now connects to akonadi for the events in the calendar.
Could it be that this is the problem?
You can deactivate the events in the clock settings, in the calendar tab.

@Beat Wolf: I don't know if Akonadi could be part of the problem, but I see a huge lag also when opening for the first time the lancelot launcher. It takes more than 30 s to pop up the first time, then subsequent openings work quickly as expected (read link on my post #12 for more info). So I think that the clock widget may trigger the problem but it's not the problem itself. Maybe also lancelot uses Akonadi? And if really the problem is Akonadi, what Akonadi does that is quick on ext4 and so slow on ext3?

I have also noticed that Lancelot is very slow the first time I open it, but I didn't think it was related. I removed Lancelot and I unchecked the "Show events" thing in the calendar. 

What I now notice is that from I see the last icon in the "loading screen" (the K icon) until the screen is loaded and it starts feeling responsive only takes a few seconds. There are still things I have to wait for, but eg. the folder view is clickable. It is difficult to quantify precisely (and know precisely where the issue is) without a lot of time at my hand since things fluctuate from time to time, but I haven't seen it load this fast in quite a while.

I noticed a common feature of laggy processes (startup, lancelot etc.): the HDD light of my laptop is on, the HDD spins but very quietly, it makes almost no sound. This does not happen on ext4 nor on ext3 with 4.6.5, so I think that the slow disk activity is this "quiet spinning". I have no idea of what the HDD may be doing during these periods...

I tried 4.8 beta1 but it is as laggy as 4.7.x on ext3. The only thing I could not check is lancelot since in beta1 it does not pop up the menu at all...
I tried also deleting .kde4 and cache folder on /var/tmp, but I saw no improvement.

I had a spare partition on my HDD (the Windows recovery :P ), so I formatted it as ext4 and mounted as /var/tmp. The system is now responsive as one might expect, startup is fast and I don't experience lags anymore: the desktop is immediately usable after booting.
So, at least for me, the problem is actually having an ext3 /var/tmp. Hope this can help other people and give some hints to the devs...

hi, after entering password in KDM plasma is loading about 15s on fresh boot (core2duo e6300 1.86GHz, 2GB ram), out of curiosity I've run plasma from terminal and I get a lot of:

-------------------------------------------------------------------------------
ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error)
search paths:  ("/usr/local/bin", "/usr/bin", "/bin", "/usr/local/sbin", "/usr/sbin", "/sbin", "/opt/java/jre/bin", "/usr/bin/core_perl", "/usr/sbin", "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin") 
Found mysql_install_db:  "/usr/bin/mysql_install_db" 
Found mysqlcheck:  "/usr/bin/mysqlcheck" 
Failed to use database "akonadi" 
Database error: "Can't connect to local MySQL server through socket '/home/yoda/.local/share/akonadi/socket-renata-PC/mysql.socket' (2) QMYSQL: Unable to connect" 
Trying to create database now... 
QSqlDatabasePrivate::removeDatabase: connection 'initConnection' is still in use, all queries will cease to work.
Database error: Cannot open database.
Last driver error: "QMYSQL: Unable to connect"
Last database error: "Can't connect to local MySQL server through socket '/home/yoda/.local/share/akonadi/socket-renata-PC/mysql.socket' (2)"
Unable to open database "Can't connect to local MySQL server through socket '/home/yoda/.local/share/akonadi/socket-renata-PC/mysql.socket' (2) QMYSQL: Unable to connect"
"[
-------------------------------------------------------------------------------

but I intentionally disabled akonadi via ~/.config/akonadi/akonadiserverrc so why plasma still wants to run akonadi? I forgot to disable "show events" in systemclock and now this error shows just once, why in heavens name those super star trek alien technology features are so hard to disable? I admire KDE vision but not everything of next-gen semantic desktop works right now as it should be, also a lot of people doesn't use this at all! Those things should be DISABLED by default. We are living in the era where Amarok needs full blown sql database and 300MB of ram just o play ONE mp3! something is not right

(In reply to comment #22)
> but I intentionally disabled akonadi via ~/.config/akonadi/akonadiserverrc

You just disabled the MySQL startup in this config, not the akonadi. Therefore, it tries to start, but fails because of stopped MySQL.

I prefer to use sqlite for akonadi (because I don't use it at all now) — just change «Driver» to QSQLITE3 in akonadiserverrc. With sqlite it starts instantaneously. Also, you might want to disable various akonadi-depended krunner plugins to prevent automatic akonadi startup.

Cheers.

@Nikolay, thanks for the tips but we missing the point here. The point is: why every user of KDE is forced by default to start this bloat? I don't use kpim at all, I use thunderbird (there is a lot of users who doesn't use mail client). Also how on earth a regular user is supposed to know about .akonadiserverrc? Most of users don't even know what database is!

This is all upside down people, it should be like this:
- if kmail/kdepim package is not installed offer light desktop by default, no akonadi which eats >100MB of RAM (on some PC's this is still a lot!), all widgets that are using it are disabled, "show events" in system clock disabled (run mysql to show time it's frickin' genius). The goal is... listen closely... DESKTOP ENVIRONMENT that allows USERS to run THEIR favorite software WITHOUT bloat which 90% of users doesn't even heard about! Let users choose if they want social/semantic/something else capabilities
- if kmail/kdepim is installed that's fine, run akonadi/databases and other stuff

that's why KDE4 has been labeled slow and heavyweight... new things should be introduced to users not thrown at them even if they don't want to use them

Strace usage in the first comment is wrong, because it shows a time between two syscalls instead of a time of the syscall. So the hung is not in recvmsg(), but in the previous syscall - it's poll() for pipe. Changing strace parameters to show syscall time confirms this. According to strace, it looks like there's one thread/process waiting for another in this way. There are two plasma-desktop processes present and it looks like the second is actually loading while first one is just stuck waiting for a response from the second.

I had this problem, and fixed it.  Login was initially very fast, but then I went and tried out a large number of themes.  When I did so, each theme apparently added 84MB to /var/tmp/kdecache-username/  In total, all the files in the cache (more than just from themes) amounted to 1GB.  Then every time I went to login, it delayed for 60 seconds or more of heavy disk activity.

However, I logged out, ctrl-alt-F1'd to a terminal, deleted all the files in the cache, and now the startup is fast again.  If plasma is going to read the entire contents of this cache in, or whatever it is doing, then it should probably clear it out more regularly or put greater constraints on its size.

I must correct my previous post.  Clearing the cache, even clearing the cache each time, did not fix it.  What I mistook for success, and what DOES work fast, is logging out, and logging back in again.  However, upon a full reboot, the very long delay is still present.  I timed it as up to 5 minutes a few times now.  There is something with heavy disk activity that plasma-desktop is doing on a login after a full boot that it does not do for a login after just a logout.

@rorzik: what silesystem do you use for /var/tmp? I had exactly the same problems you report, and they were due to having /var/tmp on an ext3 partition. As you can read from post 21, I completely solved the problem by formatting a spare partition as ext4 and mounting it as /var/tmp.
I hope this can help you.

No it's not ext3 fault, it's 2012 and ext4 is standard especially for new users. I run ext4 since KDE 4.0 and IT'S KDE fault. We need to work on some optimizations (with every release is better and better but loging in still consumes to much time). Stop focusing on plasmoids, leave it to people/kde-look/kde-apps.org and make KDE lighter and faster so more people could use it!

@Nicola, /var/tmp is on an ext3 filesystem.  Following some of the suggestions here and elsewhere I tried making /var/tmp a tmpfs filesystem for 5 or 6 boots, but this did not result in any improvement at all for me.

this report is non-actionable.

it is a collection of a variety of configuration issues, unexplained (and under-examined) wall-clock timings, etc.

one part of the measure for the usefulness of a report is: can it be addressed in a way that would make it considered to be resolved? in this case, the asnwer is clearly "no" as there is no single issue, there is not even a set of well defined issues. it also relies on a rather subjective notion of "fast enough" (and across a random distribution of hardware, OSes, file systems, etc.)

while we work on performance in each release, i'm afraid this report is not the way forward to improvement.

Aaron, you are idiot!
557 votes for nothing? 30-40 boot time sec on marvell-drived SSD even with disabled semantic desktop features? And this is OK, you said?
Alright, you can ban me (ha-ha-ha), but the BUGS IS HERE, AND BUGS NEED FIXING, NOT TROLLING.

Go fuck yourself by Nepomuk.

No need to become angry Oleg.
There are indeed too many issues in that one bugreport. But you are encouraged to open new bugreports for every single one of them, but everytime with only one issue. Thank you
(i too would like for kde to start up faster, but this bugreport collection is not the way forward)