Slashdot Mirror


Optimizing KDE 3.1.x

David Lechnyr writes "This article goes into detail on optimizing KDE for speed. Typically, most distributions include pre-compiled binaries of KDE which are optimized for an Intel i386 computer. Chances are that you're running something faster than this; if so, this should help you tweak the compile process to speed things up a bit."

15 of 83 comments (clear)

  1. mandatory gentoo user post... by dotgod · · Score: 5, Informative

    Gentoo does all this by default. To compile and install optimized binaries for kde, you just type "emerge kde"

    1. Re:mandatory gentoo user post... by dotgod · · Score: 3, Insightful

      You wait for it to compile and install, which beats waiting several days waiting for redhat/mandrake, etc. to release rpms.

  2. prelink by dotgod · · Score: 4, Interesting

    Using prelink will also provide additional optimization.

    1. Re:prelink by IIEFreeMan · · Score: 4, Informative

      Prelink is not useful anymore provided you use a recent glibc (>= 2.3) ...

      This is done automatically by the libc and the dynamic linker.

    2. Re:prelink by Spy+Hunter · · Score: 3, Informative
      This is simply not true. Here's the truth straight from the source: glibc NEWS file. It says you need "additional tools" to take advantage of prelinking, and the "prelink" program is that additional tool. I have also heard other people say that prelinking is not necessary anymore, but they were wrong. Prelinking my KDE binaries on Debian unstable resulted in a noticable startup performance increase. I hope this misinformation doesn't cause people to discount prelinking as a possible performance booster.

      FYI, prelinking KDE is not easy. On Debian the QT package has OpenGL support compiled in. The OpenGL library is not prelinkable because it is not PIC (Position Independent Code). Since all KDE applications are linked to QT and thus to OpenGL indirectly, this also means that all of KDE isn't prelinkable. I don't know of any KDE app that actually uses QT's OpenGL support, so I don't know why it is compiled in. To prelink KDE I had to compile my own version of QT without OpenGL support. This works to allow prelinking, but using a a version of QT compiled with different options makes QT's style plugins not work and has other disadvantages. There are two real solutions:

      1. Compile OpenGL as PIC - I don't know why it isn't already.
      2. Compile QT without OpenGL support, and provide separate packages for people who need OpenGL support.
      I've sent emails to the debian-kde list about prelinking the Debian KDE packages, but the maintainers didn't seem interested. Hopefully they will eventually see the light and start working toward prelinking KDE.
      --
      main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
    3. Re:prelink by JohnFluxx · · Score: 4, Informative

      >I've sent emails to the debian-kde list about prelinking the >Debian KDE packages, but the maintainers didn't seem >interested. Hopefully they will eventually see the light and >start working toward prelinking KDE.

      I looked at the discussion on prelinking in Debian, and it's not all such a straight forward issue.

      When you have a binary, and run it, it loads all the libraries that the binary uses. When it loads the libraries, it basically puts it into memory, and then tells the binary the memory address of everything in the library. I think this is things like functions, data structures, etc.
      Anyway, prelinking is when you now modify the binary, and tell it about the particular version of the libraries that it links (say version 1.0.3 or whatever) Now when you run the binary and use that particular version of the library, it loads the library into a specific memory address, and the binary already knows the memory address of all the functions and data structures.
      This speeds up loading time and saves memory.
      If the library version changes, then it falls back on the old method.

      Now, the trouble is, when you update a library, you must update all the binaries. This means (as far as I see it) either you also update all the appropriate binaries by running prelink again on all the binaries, or you update the packages the binaries are in.
      The second option would cause libraries to have huge number of dependancies, and would make minor upgrades of libraries horrendous for dial up users.
      The first option has slightly more subtle problems. The problem is that it means when you update a library, it goes and unpredictably modifies binaries. This plays absolute havoc with things like tripwire, and any kind of security.

      This is merely my understanding from 5 mins research, so take it as you will.

    4. Re:prelink by IamTheRealMike · · Score: 3, Insightful

      To be more accurate, prelinking allocates each library a unique location in virtual address space and then stores the precalculated GOT (or is it the PLT) in a new section in the binary. That means you only need to do a few links, instead of a lot (due to the ELF fixup semantics, sometimes you get conflicts which must always be linked at runtime).

  3. I do this with ALL my software, automatically. by ewomack · · Score: 5, Interesting

    See http://www.sourcemage.org/ All source, downloaded from the authors site and compiled to the settings and optimizations YOU choose.

  4. Gentoo... by dh003i · · Score: 4, Insightful

    "Does" this all for you. By "does", I mean that the install guide forcefully tells you to alter your /etc/make.conf file to include support for the features you want and the optimizations you want.

    Btw, you don't just sit around for 8 hours waiting for something to compile. If you're in CLI-only, you do the following:

    emerge screen
    screen emerge kde
    C^A C^C


    Then you do whatever else you want to do. I recommend getting IRSSI and Lynx for internet-amusement.

    If you already have Xfree86 setup, then you do the following:

    emerge ratpoison
    C^A C^C


    Then run whatever graphical X-programs you want in your new ratpoison windows.

    This is the beauty of a *modern day* multi-tasking OS like GNU/Linux. This isn't the same crap as Micro$oft. You can compile something AND do other things at the same time, since memory management is great as is multi-tasking (depending on your kernel and compile options for the kernel). Try compiling something using MS's compilers and doing something else at the same time. I compiled WindowMaker, for example, while doing other tasks in ratpoison.

    As for compile-time optimizations, I recommend the following:

    CFLAGS = -march=cpu_type -Os -pipe -fomit-frame-pointer

    That will optimize for small-size binaries and minimal RAM usage. I recommend the -Os optimization for the vast majority of applications, most of which are not CPU-intensive. That includes WMs, DEs, word-processors, spreadsheets, internet browsers, e-mail programs, GIMP, etc. I recommend -O2 for things which are CPU-intensive, like video/sound players, video/sound encoders, DNA/AA sequence alignment, and bayesian phylogenies.

    Make sure to

    man gcc

    So you know what your doing. Hint: once you hit a certain point with optimization, you can't have it both ways. Higher levels of optimization involve trading a memory/speed tradeoff, and you can go one way or the other. As I suggested before, I suggest memory optimizations for non-CPU intensive programs (the one's you'll probably be using all of the time, thus which'll be clogging up your memory); and speed optimizations for CPU-intensive programs, which you probably won't use as much.

  5. Re:portage ? by dh003i · · Score: 4, Interesting

    Experimental? Come on. Maybe -O3 and then a series of other additional optimizations beyond that are experimental. But the sane optimizations most people use are not experimental. I, myself, default to:

    -march=athlon-tbird -Os -pipe -fomit-frame-pointer

    Btw, compiling everything from scratch is hardly "unstable". That's what FreeBSD does. Furthermore, memory optimizations often-times increase system-stability, by reducing the likelihood of situations where there isn't enough RAM. Furthermore, some of the USE settings increase stability by eliminating compiled-in support for crap that you don't use. If you don't use something, and support for it is compiled in, it's just useless crap that has the potential to reduce stability.

  6. Here's a script that works. by SN74S181 · · Score: 5, Funny

    This optimizes the hell out of KDE, and it reduces the memory footprint as well. It's such a simple script that I include it right in my ~/.cshrc file:

    alias kde twm

    You can substitute fvwm2 or some other window manager if you're not a tab enthusiast.

  7. Re:portage ? by larry+bagina · · Score: 5, Informative
    it's not about "experimental optimizations", it's about beling able to select instructions optimized for your CPU.

    the difference between a 386, 486, and pentium I-IV isn't just clockspeed and MMX, a handful of new instructions have been added. If you don't specify the arcitecture, you'll generate i386 compatable code.

    so if (i == 0) i = 1234; will generate code like this:
    cmp eax,0
    jne L1
    mov eax, 1234
    L1:

    A PII however, can do this:
    cmp eax,0
    cmove eax,1234

    that might not look all that much better, but branches are a huge bubble in the pipeline, and are horrible for performance.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  8. How much? by ariels · · Score: 3, Insightful

    How much performance increase are we talking here? Faster startup times? Better response times? Perceived better response?

    There's no reason to work hard without knowing what the benefits are. For that matter, say I do all this and it doesn't seem to work any faster. How do I know if I did something wrong, or if there is nothing to measure?

    --
    2 dashes and a space, or just 2 dashes?
  9. Konstruct by twener · · Score: 3, Informative

    Why not use Konstruct instead of typing all this manually?

  10. KDE performance tips by twener · · Score: 3, Informative

    I don't see where this article is talking about optimizing other then self-compiling. Better read the KDE performance tips.