Here is that back-trace for opening okular, going go file > Open and pressing ctrl + Z immediately. Although opening a new window in dolphin is equally slow as starting dolphin from scratch.

Code: Select all

Thread 3 (Thread 0x7fffdbfff700 (LWP 8452)):
#0  0x00007ffff4fc9f7d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff1bbf6a4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff1bbf7ac in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff59ceaf6 in QEventDispatcherGlib::processEvents (this=0x7fffd40008c0, flags=...)
    at kernel/qeventdispatcher_glib.cpp:427
#4  0x00007ffff59a030f in QEventLoop::processEvents (this=this@entry=0x7fffdbffed70, flags=...) at kernel/qeventloop.cpp:149
#5  0x00007ffff59a0605 in QEventLoop::exec (this=this@entry=0x7fffdbffed70, flags=...) at kernel/qeventloop.cpp:204
#6  0x00007ffff589cc4f in QThread::exec (this=this@entry=0xf1eb00) at thread/qthread.cpp:537
#7  0x00007ffff5981a33 in QInotifyFileSystemWatcherEngine::run (this=0xf1eb00) at io/qfilesystemwatcher_inotify.cpp:265
#8  0x00007ffff589f31f in QThreadPrivate::start (arg=0xf1eb00) at thread/qthread_unix.cpp:349
#9  0x00007ffff2097f6e in start_thread (arg=0x7fffdbfff700) at pthread_create.c:311
#10 0x00007ffff4fd69cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 2 (Thread 0x7fffe11d6700 (LWP 8450)):
#0  0x00007ffff4fc9f7d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff1bbf6a4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff1bbf7ac in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff59ceaf6 in QEventDispatcherGlib::processEvents (this=0x7fffdc0008c0, flags=...)
    at kernel/qeventdispatcher_glib.cpp:427
#4  0x00007ffff59a030f in QEventLoop::processEvents (this=this@entry=0x7fffe11d5d70, flags=...) at kernel/qeventloop.cpp:149
#5  0x00007ffff59a0605 in QEventLoop::exec (this=this@entry=0x7fffe11d5d70, flags=...) at kernel/qeventloop.cpp:204
#6  0x00007ffff589cc4f in QThread::exec (this=this@entry=0xedc350) at thread/qthread.cpp:537
#7  0x00007ffff5981a33 in QInotifyFileSystemWatcherEngine::run (this=0xedc350) at io/qfilesystemwatcher_inotify.cpp:265
#8  0x00007ffff589f31f in QThreadPrivate::start (arg=0xedc350) at thread/qthread_unix.cpp:349
#9  0x00007ffff2097f6e in start_thread (arg=0x7fffe11d6700) at pthread_create.c:311
#10 0x00007ffff4fd69cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 1 (Thread 0x7ffff7fac7c0 (LWP 8446)):
#0  0x00007ffff4fc9f7d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff1bbf6a4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff1bbf7ac in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff59cead5 in QEventDispatcherGlib::processEvents (this=0x611b50, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#4  0x00007ffff6435cb6 in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...)
    at kernel/qguieventdispatcher_glib.cpp:204
#5  0x00007ffff59a030f in QEventLoop::processEvents (this=this@entry=0x7fffffffda80, flags=...) at kernel/qeventloop.cpp:149
#6  0x00007ffff59a0605 in QEventLoop::exec (this=this@entry=0x7fffffffda80, flags=...) at kernel/qeventloop.cpp:204
#7  0x00007ffff59a5deb in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1225
#8  0x0000000000408276 in ?? ()
#9  0x00007ffff4efdde5 in __libc_start_main (main=0x407da0, argc=1, ubp_av=0x7fffffffdd78, init=<optimized out>,
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdd68) at libc-start.c:260
#10 0x0000000000409121 in _start ()


By the way, I just noticed something. If I start Gwenview (which also has a lag to start) and then press Ctrl + O right away, the file picker starts instantly and there is no lag. I tried with other applications: If I start the file picker, close it, and start it again right away the lag is significantly lower. If I wait a while and try ctrl + O again, there is still a lag. Is that useful at all?

bcooksley pointed out some details are cached when I do File > Open, but there is a difference between immediate subsequent File > Opens and ones that are spaced out. (As a control, running Gimp and doing Ctrl + O gives me an instant File > Open dialog every time).

Unfortunately that backtrace doesn't indicate why Dolphin appears to be slow - it seems to be processing events normally.
Without knowledge of the concrete cause, it won't be possible to attempt to fix this unfortunately.

Is there anywhere other than ~/.kde where KDE settings and such may be stored?

Depending on the sort of settings, they could also be stored in ~/.local or ~/.config.

So...I'm giving up. I'm assuming it must be my system since I installed Ubuntu and also Kubuntu 13.10 on VMs and dolphin seems ot start fine. Deleting the configuration, disabling services, or running as root didn't help the lag. This is fairly frustrating, but I guess I can't do anything more short of re-installing my system.

Many thanks for your time.

I think that whatever made dolphin slow got fixed when I upgraded KDE but I thought it was still being slow because Dolphin starts up slower than other KDE apps. I recently reinstalled my system and, on the fresh install, Dolphin starts up in a little over a second. This sounds fast but feels slow compared to other kde apps (which start up in a quarter of a second or so).

I've concluded this is the normal startup time for Dolpin in my computer. If I start Konqueror with the "Places" panel open startup is also about 1.5 seconds (like Dolphin). If I start it with the default profile then startup is back to a a quarter of a second or so.

Basically, sorry for being paranoid about Dolphin's startup time. Thanks a lot for the help! I always get good help in KDE forums.