On 17/11/17 19:35, Luigi Toscano wrote:
Terry Barnaby ha scritto:
Yes, the latest KDE5/Plasma is horrendously inefficient when it comes boot
times due to disk access requirements. With a spinning HDD system boot times
are really bad (minutes). A SSD helps this but obviously the issue is really
in KDE5/Plasma. With this aspect improved systems would be so much faster
better even with SSD's. I suspect the use of the QtQuick (QtSlow!) technology
is to blame reading loads of small files describing GUI interface parts rather
than just using C++. With a standard fast HDD, a 3 GHz quad core i5 type
machine takes much longer to boot than an old 400 MHz single core Pentium
Laptop with 256 MBytes of RAM and an slow 2.5inch HDD running an old Fedora
with KDE3. The price of bad software "progress".
I think that a blank statement like "QtQuick produces the slow startup" should
be backed by some statement, not just by "I think".
For example, I remember some time ago a set of patches in few libraries part
of Frameworks to improve the lookup of the icons, which was hitting the
startup of same applications, and it was not related to QtQuick or QtWidgets.
This is to underline the fact that "tons of small files" may not be the
problem, especially because they can be put together in a resource file.
I didn't say "QtQuick produces the slow startup", I said "I suspect ..." :)
A statement like "QtQuick produces the slow startup" should indeed be
backed up by some evidence, that would take a bit of work to concisely
determine what is happening and would have to be performed by those who
know some of the details of the architecture of the KDE5/Plasma system.
It is a fact that KDE5/Plasma is slow to boot/start up on a spinning
HDD. There are some figures I and others have posted a while back in
this list and lots of people recommend using an SSD when using
KDE5/Plasma. As the boot/startup speed difference between a spinning HDD
and SSD is so dramatic, this points to lots of small file accesses (seek
times are the main culprit of slow HDD access).
I just did some quick and simple tests by using "strace -f -tt -e
trace=open,execve -o /tmp/strace_startkde.txt /usr/bin/startkde1" in a
shell script place of /usr/bin/startkde (/usr/bin/startkde moved to
/usr/bin/startkde1).
With my Fedora25 KDE/Plasma login (Dual monitor and has a manual session
setup with Thunderbird, Firefox, Dolphin and 8 konsoles, NFS /home/... )
there are 62122 file opens. (A virgin system default KDE5/Plasma
boot/startup still takes a relatively long time). This does include
shared libraries /dev, /sys accesses etc. and so a lot of these can
perhaps not be really considered as a real file access.
Ignoring /lib64/*, /dev/*, /sys/* and /run/* accesses there are 17276
file opens. The boot/start up takes 52 seconds on a i5-3450 CPU @
3.10GHz system with a fast SSD with the strace running.
As far as QtQuick, assuming these are the just "*.qm" and "*.qml" files
only there are 1194 file accesses so maybe it isn't the QtQuick side
that is the main issue but we would have to time each file read access
to really see where the time is being used.
This needs more work, but 62122 file opens just to login to a
KDE5/Plasma session seems a bit high !
Terry
_______________________________________________
kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kde-leave@xxxxxxxxxxxxxxxxxxxxxxx
