[Digikam-devel] [Bug 198063] Digikam startup is extremely slow
Andi Clemens
andi.clemens at gmx.net
Wed Jul 1 13:19:41 BST 2009
https://bugs.kde.org/show_bug.cgi?id=198063
--- Comment #11 from Andi Clemens <andi clemens gmx net> 2009-07-01 14:19:35 ---
When using strace -c, you get some kind of "call graph". Sure it is not that
accurate then using callgrind or gprof, but at least it give some useful
information:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
38.71 452.126188 10665 42393 508 stat64
15.53 181.369525 10659 17016 9687 read
14.35 167.568354 7106 23580 17458 access
5.01 58.565473 10666 5491 clock_gettime
4.08 47.689382 10647 4479 select
2.51 29.307504 10665 2748 241 lstat64
2.41 28.108221 10603 2651 writev
2.24 26.171927 10665 2454 gettimeofday
1.85 21.575460 10665 2023 399 open
1.61 18.791730 10665 1762 _llseek
1.57 18.293895 10667 1715 time
1.50 17.525235 10545 1662 close
1.14 13.309920 10665 1248 fstat64
1.06 12.403395 10665 1163 mmap2
0.99 11.562332 10666 1084 getdents
0.81 9.481194 10665 889 fcntl64
0.56 6.531191 10483 623 write
0.49 5.769765 10665 541 statfs
0.48 5.641834 10665 529 inotify_add_watch
0.48 5.641785 10665 529 inotify_rm_watch
0.45 5.303356 10481 506 munmap
0.38 4.490636 10769 417 poll
0.35 4.126428 10089 409 54 futex
0.30 3.512119 10675 329 ioctl
0.17 2.026389 10665 190 15 unlink
0.17 1.979691 10701 185 brk
0.10 1.141155 10665 107 mprotect
0.09 1.098495 10665 103 getcwd
0.08 0.938520 10665 88 uname
0.07 0.778545 10665 73 fchmod
0.07 0.767920 10666 72 link
0.07 0.767880 10665 72 fstatfs
0.03 0.383940 10665 36 clone
0.03 0.351945 10665 33 getuid32
0.02 0.255960 10665 24 socket
0.02 0.255960 10665 24 shmctl
0.01 0.170640 10665 16 getpeername
0.01 0.159975 10665 15 bind
0.01 0.159975 10665 15 listen
0.01 0.149310 10665 14 accept
0.01 0.149310 10665 14 getsockname
0.01 0.149310 10665 14 getsockopt
0.01 0.095985 10665 9 4 connect
0.01 0.095985 10665 9 semop
0.01 0.095985 10665 9 semctl
0.01 0.085320 10665 8 readlink
0.01 0.063990 10665 6 mlock
0.01 0.063990 10665 6 geteuid32
0.01 0.063990 10665 6 madvise
0.01 0.063990 10665 6 getdents64
0.01 0.063990 10665 6 shmat
0.01 0.063990 10665 6 shmdt
0.01 0.063990 10665 6 shmget
0.00 0.053325 10665 5 sched_get_priority_min
0.00 0.053325 10665 5 getgid32
0.00 0.042660 10665 4 kill
0.00 0.042660 10665 4 fdatasync
0.00 0.042660 10665 4 sched_get_priority_max
0.00 0.031995 10665 3 getegid32
0.00 0.031995 10665 3 clock_getres
0.00 0.031995 10665 3 semget
0.00 0.021330 10665 2 umask
0.00 0.021330 10665 2 rt_sigprocmask
0.00 0.010665 10665 1 execve
0.00 0.010665 10665 1 chmod
0.00 0.010665 10665 1 lseek
0.00 0.010665 10665 1 rename
0.00 0.010665 10665 1 1 mkdir
0.00 0.010665 10665 1 pipe
0.00 0.010665 10665 1 sched_getparam
0.00 0.010665 10665 1 sched_getscheduler
0.00 0.010665 10665 1 getrlimit
0.00 0.010665 10665 1 fchown32
0.00 0.010665 10665 1 set_thread_area
0.00 0.010665 10665 1 set_tid_address
0.00 0.010665 10665 1 inotify_init
0.00 0.010665 10665 1 set_robust_list
0.00 0.010665 10665 1 SYS_331
0.01 0.135977 9713 14 rt_sigaction
0.00 0.029327 7332 4 getpid
------ ----------- ----------- --------- --------- ----------------
100.00 1168.071528 117481 28367 total
I started digiKam and immediately closed it again. As you can see, stat64 took
nearly 40% of all the executed calls.
This would explain why the KDE4 version, although scanning is disabled, is much
slower then the KDE3 version (as Martin already mentioned).
KDE4 seems to do a lot more then KDE3 did here. I never really worked with the
KDE3 code of digiKam so I don't know which techniques we used there.
Also I'd like to mention that loading the plugins is slower then in KDE3, too.
Maybe we could load them parallel? We only have 20 plugins, wouldn't it be
possible to load them all at once by using threads? They don't depend on each
other, so we actually don't need to wait before another plugin can be loaded.
Or wouldn't this be possible?
Andi
--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the Digikam-devel
mailing list