Announcement

Collapse
No announcement yet.

KDE Plasma 5.13 Beta Released With A Compelling Number Of Improvements

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Kver View Post

    There is a project to do so called "Blade", I think being spearheaded by Ivan. It's using multiple processes with an asynchronous design and has other advantages too, such as simplification of the codebase, but from what I understand it's a while off before it's ready to replace Krunner.
    Good to hear that it's moving somewhere

    Comment


    • #32
      Originally posted by ⲣⲂaggins View Post

      "Resources are there to be used. Therefore, let's write lazy inefficient code so that all those free resources which would otherwise be wasted get used!"

      I do not understand this mantra that unused RAM is wasted RAM. Inefficiently-used memory is worse than unused memory, because it negatively impacts other uses like the disk cache.
      Except that some of what the desktop is storing in RAM is exactly that - a used disk cache targeting exactly what it needs rather than relying on the OS to guess.

      Sure, you could have it load everything from disk on demand if you really wanted everything to be slower, but why not just store those icons in RAM where they can be accessed quickly?

      Obviously if an app is blatantly wasting RAM that's not great, but I've yet to see a single person complain about their desktop using too much RAM actually explore what it is being used for and if it's truly wasted or just being used efficiently in order to make sure things run fast. Wasting = bad, Using = good, and it's never black and white like everyone pretends. And at the end of the day, wasting 20MB these days is a non-factor. Complaining about it is like being that guy who constantly gripes that the temp is 1 degree to hot or cold and won't ever shut up about it.
      Last edited by smitty3268; 25 May 2018, 12:26 AM.

      Comment


      • #33
        I wouldn't call an icon cache a waste of memory, or anything whose purpose is to improve performance at the expense of a little memory used.

        But there is also real, blatant inefficiency. If you want to see what I mean, look at how many times the same config files are opened and parsed on startup of an application using strace, or take a look at Konsole's history file format.

        What bugs me is users defending the latter, because they claim it doesn't matter if there are enough resources, which should never be an excuse for writing sloppy code.
        Last edited by ⲣⲂaggins; 26 May 2018, 07:32 AM. Reason: Don't use vbulletin on a phone

        Comment


        • #34
          Originally posted by ⲣⲂaggins View Post
          For those complaining about login times, I've found two things make a huge difference:
          • Turn off QT_LOGGING_RULES, to suppress the default generation of vast swathes of debug messages.
          • Run it under libeatmydata to defers disk syncs, which kde makes a lot of during login.
          Qo you actually tried it?
          I've had qt logging already disabled, but i just tried with libeatmydata preloaded:
          Code:
          koko@Gozer# cat ~/.xinitrc
          sudo sync ; sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" ; sleep 1 ; free
          export LD_PRELOAD="/usr/local/lib/libeatmydata.so"
          startkde
          With libeatmydata it started in 38 seconds; withhout it, it started in 35 seconds.
          If it doesn't slowed down the process, then it made no difference at all to me. Rotative disk.
          i can tell you that libatemydata preload is working on my system according to dd:

          Code:
          koko@Gozer# LD_PRELOAD=/usr/local/lib/libeatmydata.so dd if=/dev/zero of=~/tmp/zero bs=1K count=100000 conv=fsync
          100000+0 records in
          100000+0 records out
          102400000 bytes (102 MB, 98 MiB) copied, 0,274801 s, 373 MB/s
          
          koko@Gozer# dd if=/dev/zero of=~/tmp/zero bs=1K count=100000 conv=fsync
          100000+0 records in
          100000+0 records out
          102400000 bytes (102 MB, 98 MiB) copied, 0,701972 s, 146 MB/s
          And i cant tell for sure that it has been preloaded, according to plasmashell environment:
          Code:
          koko@Gozer# strings /proc/`pidof plasmashell`/environ |grep LD_PRELOAD
          LD_PRELOAD=/usr/local/lib/libeatmydata.so
          So it seems that kde devs are using fsyncs just fine (?)

          Comment


          • #35
            kokoko3k

            I'm surprised by your benchmarks, as I've tested this myself. I assume you're comparing cold login time; have you tried hot login?

            Comment


            • #36
              Originally posted by petete View Post

              You don't need the DE to support AppImage. Just mark it as executable and run it.
              I know about that, but I think I saw in Cinnamon or other DE good support where a pop-up appears when you double click on it where it asks you if you want to make it executable and run it and also if you want to install it permanently.
              This is the kind of support that I want in KDE too.

              Comment

              Working...
              X