[dolphin] [Bug 430241] New: Dolphin takes a very long time to tart

[Razathorn]

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

            Bug ID: 430241
           Summary: Dolphin takes a very long time to tart
           Product: dolphin
           Version: 20.08.2
          Platform: Kubuntu Packages
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: dolphin-bugs-null at kde.org
          Reporter: raz at chewies.net
                CC: kfm-devel at kde.org
  Target Milestone: ---

Created attachment 133986
  --> https://bugs.kde.org/attachment.cgi?id=133986&action=edit
strace with timestamps

SUMMARY
When opening dolphin on raspberry pi 4 on ubuntu 20.10, dolphin takes
excessively long (4-5 seconds) to open.  STRACE seems to indicate grinding on
/dev/dri and /dev/dri/* directory, iterating through many dri "devices or
renders" (I'm not sure what the devices do).  Once launched, dolphin performs
normally (and in fact, is very fast).

STEPS TO REPRODUCE
1. Open dolphin


OBSERVED RESULT
Dolphin takes ~5 seconds to start.

EXPECTED RESULT
Dolphin should take far less than 5 seconds to start as nearly every other kde
program, or GIMP for example.  This is definitely a CPU constrained device, but
there is clearly some sort of issue at play when examining strace output.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Ubuntu Desktop 20.10 (kubuntu-desktop packages/task
installed)
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.14.2

ADDITIONAL INFORMATION
Raspberry pi 4B w/ 8G ram running on sd card.

Full strace with times attached, here is a summary of the system calls:
------
raz at nibble:~$ cat dolphin.log | sort | uniq -c | sort -nr | head -10
   3756 newfstatat(AT_FDCWD, "/dev/dri", {st_mode=S_IFDIR|0755, st_size=120,
...}, 0) = 0
   3750 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=20000}, NULL) = 0
------

And here is a snippet of an example "grind iteration" against DRI targets:
------
19:16:36.103698 newfstatat(AT_FDCWD, "/dev/dri", {st_mode=S_IFDIR|0755,
st_size=120, ...}, 0) = 0 <0.000038>
19:16:36.103877 newfstatat(AT_FDCWD, "/dev/dri/renderD141", 0xfffff95d3740, 0)
= -1 ENOENT (No such file or directory) <0.000036>
19:16:36.104015 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=20000},
NULL) = 0 <0.000104>
19:16:36.104214 newfstatat(AT_FDCWD, "/dev/dri", {st_mode=S_IFDIR|0755,
st_size=120, ...}, 0) = 0 <0.000030>
19:16:36.104356 newfstatat(AT_FDCWD, "/dev/dri/renderD141", 0xfffff95d3740, 0)
= -1 ENOENT (No such file or directory) <0.000033>
19:16:36.104488 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=20000},
NULL) = 0 <0.000103>
19:16:36.104688 newfstatat(AT_FDCWD, "/dev/dri", {st_mode=S_IFDIR|0755,
st_size=120, ...}, 0) = 0 <0.000030>
19:16:36.104823 newfstatat(AT_FDCWD, "/dev/dri/renderD141", 0xfffff95d3740, 0)
= -1 ENOENT (No such file or directory) <0.000034>
19:16:36.104955 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=20000},
NULL) = 0 <0.000103>
19:16:36.105153 newfstatat(AT_FDCWD, "/dev/dri", {st_mode=S_IFDIR|0755,
st_size=120, ...}, 0) = 0 <0.000030>
19:16:36.105287 newfstatat(AT_FDCWD, "/dev/dri/renderD141", 0xfffff95d3740, 0)
= -1 ENOENT (No such file or directory) <0.000032>
19:16:36.105417 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=20000},
NULL) = 0 <0.000102>
-----

It appears to "failure iterate" across a lot of /dev/dri/renderDXXX devices
following this pattern.

-- 
You are receiving this mail because:
You are on the CC list for the bug.