Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Test: KDE SC 4.7 auf dem Weg zur…

Performancegewinne?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Performancegewinne?

    Autor: zilti 27.07.11 - 15:33

    Wie sieht es mit Netbooks aus, ist eine Performancesteigerung feststellbar? Bei mir ist 4.6 nämlich des öfteren etwas lahm, sodass ich mir überlege, auf dem Netbook auf E17 umzusteigen.

  2. Re: Performancegewinne?

    Autor: Seitan-Sushi-Fan 27.07.11 - 15:42

    KDE kann kaputte Treiber nicht reparieren. Fast alle Performance-Beschwerden gehen darauf zurück, dass manche Treiber gewisse OpenGL-Funktionen nur sehr langsam ausführen können.

  3. Re: Performancegewinne?

    Autor: zilti 27.07.11 - 17:24

    Nutzt denn KDE bei abgestellten Arbeitsflächeneffekten überhaupt OpenGL? Und trotzdem könnte es ja sein, dass sie da irgendetwas optimiert hätten.
    Ich sage ja nicht "Scheiss-KDE ist saulangsam". Mir ist bewusst dass ich meinem Netbook mit KDE 4 doch ziemlich viel zumute, insbesondere wenn dann noch Opera mit über 20 Tabs und ab und an IDEA offen ist.

  4. Re: Performancegewinne?

    Autor: Non_Paternalist 27.07.11 - 20:05

    Naja, hängt von deinem Netbook ab. Sofern Dein Netbook "älterer" Generation ist, kann dies durchauszutreffen, aber etwas modernere Netbooks haben mit KDE-Software wohl nicht mehr so die Probleme, zumal in den neueren Softwareversionen immer mehr und mehr Speicherregressionen und Performanceprobleme durch Optimierungen ausgebügelt werden.

    Sofern du dann noch vernünftige Treiberunterstützung hast, sollte es nicht allzu arg werden.

  5. Re: Performancegewinne?

    Autor: Hello_World 27.07.11 - 21:17

    Seitan-Sushi-Fan schrieb:
    --------------------------------------------------------------------------------
    > KDE kann kaputte Treiber nicht reparieren. Fast alle
    > Performance-Beschwerden gehen darauf zurück, dass manche Treiber gewisse
    > OpenGL-Funktionen nur sehr langsam ausführen können.
    Das sind einfach faule Ausreden, die niemanden weiter bringen. Wenn die Treiber die gewünschten Funktionen nicht schnell genug ausführen können, muss man es eben irgendwie anders machen. E17 beweist ja, dass es geht. Das ist viel schneller als KDE4, ohne deswegen schlechter auszusehen (eher umgekehrt).

  6. Re: Performancegewinne?

    Autor: zilti 27.07.11 - 21:28

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > Das sind einfach faule Ausreden, die niemanden weiter bringen. Wenn die
    > Treiber die gewünschten Funktionen nicht schnell genug ausführen können,
    > muss man es eben irgendwie anders machen. E17 beweist ja, dass es geht. Das
    > ist viel schneller als KDE4, ohne deswegen schlechter auszusehen (eher
    > umgekehrt).
    Ja, und weisst du, warum? Weil du Äpfel mit Birnen vergleichst. Wenn schon müsstest du E17 mit KWin vergleichen. KDE ist weit mehr als E17, da gibts noch viele Hintergrunddienste die laufen und eine Palette Libraries. Das hat man bei E17 viel weniger.

  7. Re: Performancegewinne?

    Autor: Giesi35 27.07.11 - 23:22

    zilti schrieb:
    --------------------------------------------------------------------------------
    > Wie sieht es mit Netbooks aus, ist eine Performancesteigerung feststellbar?
    > Bei mir ist 4.6 nämlich des öfteren etwas lahm, sodass ich mir überlege,
    > auf dem Netbook auf E17 umzusteigen.


    Das "Problem" bei KDE SC ist das Laden der teilweise großen Bibliotheken, was vor allem auf alten Rechnern merkbar ist. Nen Ansatz ist das Prelinking (http://wiki.ubuntuusers.de/prelink).

    zilti hat recht. Man kann einen Fenstermanager nicht mit einem SC (KDE SoftwareCompilation) vergleichen. KWin (der Fenstermanager von KDE) ist nur ein kleiner Teil des Ganzen.

  8. Re: Performancegewinne?

    Autor: Hello_World 28.07.11 - 01:58

    zilti schrieb:
    --------------------------------------------------------------------------------
    > Ja, und weisst du, warum? Weil du Äpfel mit Birnen vergleichst. Wenn schon
    > müsstest du E17 mit KWin vergleichen. KDE ist weit mehr als E17, da gibts
    > noch viele Hintergrunddienste die laufen und eine Palette Libraries. Das
    > hat man bei E17 viel weniger.
    Hintergrunddienste und Bibliotheken machen nicht irgendwie auf magische Art die grafische Oberfläche langsamer. Es geht mir einfach nur darum, wie langsam die Oberfläche unter KDE teilweise gezeichnet wird. Wenn ich beispielsweise systemsettings starte, sehe ich, wie erst ein leeres Fenster auftaucht und dann ca. 1/2 bis 1 Sekunde später wird der Inhalt gezeichnet. Und wenn ich das Fenster dann größer ziehe, tauchen am Rand immer wieder leere Bereiche auf, bis sich die Bedienelemente im Fenster mit einer sichtbaren Verzögerung der neuen Fenstergröße anpassen. Und das sehe ich seit Jahren unter KDE4, während E17 keine derartigen Probleme hat.

  9. Re: Performancegewinne?

    Autor: Seitan-Sushi-Fan 28.07.11 - 02:10

    Hello_World schrieb:
    -----------------------------------------------------
    > Das sind einfach faule Ausreden, die niemanden weiter bringen. Wenn die
    > Treiber die gewünschten Funktionen nicht schnell genug ausführen können,
    > muss man es eben irgendwie anders machen.
    Wenn hier jemand FAULE Ausreden anführt, dann DU. Du willst mit Deinen faulen Ausreden kaputte Treiber rechtfertigen. Möp, gilt nicht!
    Die Treiber sind diejenigen Komponenten, sie von Milliarden schweren Unternehmen (Intel, NVidia, AMD) geschrieben werden. KDE ist zum Großteil eine Community aus Hobby-Entwicklern, die nicht die Ressourcen oder gar die Verpflichtung hätten, um irgendwelche Treiber-Bugs herum zu programmieren.

    > E17 beweist ja, dass es geht.
    Wenn E17 was beweist, dann dass man so armselig sein kann und seit über 10 Jahren keinen finalen Release einer 0.17-Version hinzukriegen. E17 ist tot und zuckt nur noch.

  10. Re: Performancegewinne?

    Autor: scroogie 28.07.11 - 08:46

    >Es geht mir einfach nur darum, wie langsam die Oberfläche unter KDE teilweise
    >gezeichnet wird. Wenn ich beispielsweise systemsettings starte, sehe ich, wie erst ein
    >leeres Fenster auftaucht und dann ca. 1/2 bis 1 Sekunde später wird der Inhalt gezeichnet.
    >Und wenn ich das Fenster dann größer ziehe, tauchen am Rand immer wieder leere
    >Bereiche auf, bis sich die Bedienelemente im Fenster mit einer sichtbaren Verzögerung
    >der neuen Fenstergröße anpassen.

    Du könntest mal probieren eine Applikation von der commandline mit

    -graphicssystem raster
    oder eben
    -graphicssystem opengl

    zu starten, um zu sehen ob es am Grafiktreiber liegt.

  11. Re: Performancegewinne?

    Autor: Hello_World 28.07.11 - 09:26

    Seitan-Sushi-Fan schrieb:
    --------------------------------------------------------------------------------
    > Hello_World schrieb:
    > -----------------------------------------------------
    > Wenn hier jemand FAULE Ausreden anführt, dann DU. Du willst mit Deinen
    > faulen Ausreden kaputte Treiber rechtfertigen. Möp, gilt nicht!
    > Die Treiber sind diejenigen Komponenten, sie von Milliarden schweren
    > Unternehmen (Intel, NVidia, AMD) geschrieben werden. KDE ist zum Großteil
    > eine Community aus Hobby-Entwicklern, die nicht die Ressourcen oder gar die
    > Verpflichtung hätten, um irgendwelche Treiber-Bugs herum zu programmieren.
    Wayne interessiert's? Ich bewerte Software danach, wie gut sie funktioniert, nicht danach, wer sie geschrieben hat. Ob Riesenfirma oder Community ist mir da vollkommen wurst.
    Zumal mir auch noch niemand einen schlüssigen Beweis dafür präsentieren konnte, dass es wirklich an dem Treiber liegt. Ich zweifle nämlich daran.

    > Wenn E17 was beweist, dann dass man so armselig sein kann und seit über 10
    > Jahren keinen finalen Release einer 0.17-Version hinzukriegen. E17 ist tot
    > und zuckt nur noch.
    Offensichtlich hast Du E17 nie ausprobiert.

  12. Re: Performancegewinne?

    Autor: Hello_World 28.07.11 - 09:27

    scroogie schrieb:
    --------------------------------------------------------------------------------
    > Du könntest mal probieren eine Applikation von der commandline mit
    >
    > -graphicssystem raster
    > oder eben
    > -graphicssystem opengl
    >
    > zu starten, um zu sehen ob es am Grafiktreiber liegt.
    raster bringt wenig bis nichts, opengl macht es nur noch langsamer. Hardware ist eine Radeon 4200 (onboard) mit dem radeon-Treiber



    1 mal bearbeitet, zuletzt am 28.07.11 09:28 durch Hello_World.

  13. Re: Performancegewinne?

    Autor: Giesi35 28.07.11 - 12:26

    Ich habe genau dieselbe GraKa und bei mir läufts flüßig und einwandfrei!

    Hintergrund-Dienste und Bibliotheken machen die Oberfläche langsam! Die Bibliotheken werden dynamisch zur Laufzeit geladen! Das dauert natürlich und dann wird erst gezeichnet! Prelinking hilft ab!

  14. Re: Performancegewinne?

    Autor: Hello_World 28.07.11 - 20:13

    Giesi35 schrieb:
    --------------------------------------------------------------------------------
    > Ich habe genau dieselbe GraKa und bei mir läufts flüßig und einwandfrei!
    Das ist schön für Dich.

    > Hintergrund-Dienste und Bibliotheken machen die Oberfläche langsam!
    Nö, nicht per se. Es ist ja nicht so, dass Enlightenment keine Bibliotheken verwenden würde. Im Gegenteil.

    > Die
    > Bibliotheken werden dynamisch zur Laufzeit geladen! Das dauert natürlich
    > und dann wird erst gezeichnet!
    Wenn Qt erst noch geladen werden müsste, könnte es auch kein Fenster erzeugen, das kann also kein Grund sein. Zudem sind die Verzögerungen ja auch zu beobachten nachdem das Programm schon längst gestartet wurde und die Bibliotheken schon im Speicher liegen.

  15. Re: Performancegewinne?

    Autor: Seitan-Sushi-Fan 29.07.11 - 02:05

    Hello_World schrieb:
    -----------
    > Wayne interessiert's? Ich bewerte Software danach, wie gut sie
    > funktioniert, nicht danach, wer sie geschrieben hat.

    Wenn das so wäre, würdest Du auf die Treiber schimpfen.


    > Zumal mir auch noch niemand einen schlüssigen Beweis dafür präsentieren
    > konnte, dass es wirklich an dem Treiber liegt. Ich zweifle nämlich daran.
    Es gibt genügend Beweise, angefangen im Blog vom KWin-Hauptentwickler. Entweder bist Du zu faul, selbst nach Gründen zu suchen (das Blog kann man nämlich leicht finden), oder Du lügst verdammt frech.
    Wie auch immer: Die Beweise gibt es.

    > > Wenn E17 was beweist, dann dass man so armselig sein kann und seit über 10
    > > Jahren keinen finalen Release einer 0.17-Version hinzukriegen. E17 ist tot
    > > und zuckt nur noch.
    > Offensichtlich hast Du E17 nie ausprobiert.
    Hat doch gar nichts mit dem Thema zu tun.
    Dass das Enlightenment-Projekt seit ca. 10 Jahren an seinem 0.17-Release (aka. E17) arbeitet und er bis heute nicht fertig gestellt wurde, ist Fakt und hat rein gar nichts damit zu tun, ob man E17 ausprobiert hat oder nicht.

  16. Re: Performancegewinne?

    Autor: lear 29.07.11 - 10:38

    Hello_World schrieb:
    --------------------------------------------------------------------------------

    > Wenn ich beispielsweise systemsettings starte, sehe ich, wie erst ein leeres Fenster
    > auftaucht und dann ca. 1/2 bis 1 Sekunde später wird der Inhalt gezeichnet.
    Hört sich nach 'nem üblen Bug in der XSYNC implementierung an, der irgendwie in KDE 4.4 & 4.5 existiert hat und sporadisch aufgetreten ist, ab 4.6 aber gegessen sein sollte.
    Wenn es am Treiber läge, hätte das raster graphicssystem es überspielen sollen - das rendert auf der CPU und ist schneller als viele Treiber + GPU :-(

    Wenn es nicht KDE/KWin sondern systemsettings spezifisch ist, dauert das laden der Konfigurationsmodule (start) eben so lange (vielleicht liegt noch ein Haufen alter == ungültiger Plugins irgendwo rum? Starte es mal aus der Textshell)

    > Und wenn ich das Fenster dann größer ziehe, tauchen am Rand immer wieder
    > leere Bereiche auf, bis sich die Bedienelemente im Fenster mit einer
    > sichtbaren Verzögerung der neuen Fenstergröße anpassen.
    Das ist die Sache mit dem XSYNC Protokoll, daß das eigentlich vermeiden sollte. Allerdings können die Clients intern Resize events immer noch sammeln und im Batch ausführen, was je nach zu veränderndem Objekt (Größenänderungen können viele Positionskalkulationen resp. Skalierungen nach sich ziehen) die CPU deutlich entlastet. Das ist dann aber clientspezifisch und der selbe Client würde sich unter E17 genaus verhalten wie unter allen anderen DEs (und E17 ist schon irgendwo zwischen WM und DE)

    > Und das sehe ich seit Jahren unter KDE4
    wie wär's mal mit 'nem update (scnr) :-P

    PS: wo ist denn der Link zu Deinem Bugreport?

  17. Re: Performancegewinne?

    Autor: Hello_World 30.07.11 - 20:44

    Mit Trollen, die mich der Lüge bezichtigen, diskutiere ich nicht.

  18. Re: Performancegewinne?

    Autor: ap (Golem.de) 30.07.11 - 20:56

    Außer Beleidigungen sind keine Inhalte mehr in diesem Thread zu finden, deshalb wurde der Thread geschlossen.

    --
    Andy Prahl
    (Golem.de)

  19. Re: Performancegewinne?

    Autor: Hello_World 30.07.11 - 21:01

    lear schrieb:
    --------------------------------------------------------------------------------
    > Hört sich nach 'nem üblen Bug in der XSYNC implementierung an, der
    > irgendwie in KDE 4.4 & 4.5 existiert hat und sporadisch aufgetreten ist, ab
    > 4.6 aber gegessen sein sollte.
    Naja, hier tritt es mit KDE 4.6.5 jedenfalls noch auf.

    > Wenn es am Treiber läge, hätte das raster graphicssystem es überspielen
    > sollen - das rendert auf der CPU und ist schneller als viele Treiber + GPU
    > :-(
    >
    > Wenn es nicht KDE/KWin sondern systemsettings spezifisch ist, dauert das
    > laden der Konfigurationsmodule (start) eben so lange (vielleicht liegt noch
    > ein Haufen alter == ungültiger Plugins irgendwo rum? Starte es mal aus der
    > Textshell)
    systemsettings gibt nur eine Zeile aus, die offenbar nichts mit dem Problem zu tun hat ("systemsettings(2298)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:")

    > Das ist die Sache mit dem XSYNC Protokoll, daß das eigentlich vermeiden
    > sollte. Allerdings können die Clients intern Resize events immer noch
    > sammeln und im Batch ausführen, was je nach zu veränderndem Objekt
    > (Größenänderungen können viele Positionskalkulationen resp. Skalierungen
    > nach sich ziehen) die CPU deutlich entlastet. Das ist dann aber
    > clientspezifisch und der selbe Client würde sich unter E17 genaus verhalten
    > wie unter allen anderen DEs (und E17 ist schon irgendwo zwischen WM und
    > DE)
    Ja, unter E17 tritt das Problem nicht auf (also nicht dass wir uns missverstehen: Die Größenänderung eines systemsettings-Fensters ist immer noch lahm, aber wenigstens sind das Fenster selbst und sein Inhalt immer gleich groß.

    > wie wär's mal mit 'nem update (scnr) :-P
    >
    > PS: wo ist denn der Link zu Deinem Bugreport?
    Jetzt wo ich einen Hinweis auf die Fehlerursache habe (XSYNC), werde ich das wohl demnächst mal machen. Danke übrigens für das erste konstruktive Posting in diesem Thread.



    1 mal bearbeitet, zuletzt am 30.07.11 21:01 durch Hello_World.

  20. Re: Performancegewinne?

    Autor: lear 31.07.11 - 19:13

    Hello_World schrieb:

    > Ja, unter E17 tritt das Problem nicht auf (also nicht dass wir uns
    > missverstehen: Die Größenänderung eines systemsettings-Fensters ist immer
    > noch lahm, aber wenigstens sind das Fenster selbst und sein Inhalt immer
    > gleich groß.

    Ok, das ist was anderes - der Bug war gravierend (der Fensteraufbau konnte sich bei jedem update über mehrere Sekunden hinziehen), daß hier ist eher lästig und dürfte einfach zu fixen sein.
    (Das XSYNC protokoll funktioniert; wenn der client lange braucht pausiert kwin irgendwann die resize Versuche - es scheint nur so, daß die Fensterdecoration den resize auch bei Vergrößerungen kriegt wenn kwin den request zum client schickt und nicht erst wenn der sagt: "ok")

    Es hat hier bis eben (Arch, e17svn kommt gerade neu rein) unter E17 übrigens auch nicht richtig funtioniert - E17 scheint den selben Fehler in die andere Richtung zu machen, so daß bei Verkleinerungen zuerst der client und dann (mit deutlicher Verzögerung) die Dekoration verändert wird.

    Der einzige WM, bei dem es "richtig" läuft ist Compiz, allerdings sind resizes damit hier (verglichen mit allen anderen WMs) so uuuuunglaublich lahm, daß ich befürchte, daß der pixelweise resize requests versendet.
    => compiz und kwin mit compositing haben als workarounds texture stretching im Angebot.
    Nachteil: kein feedback über änderungen im client.
    Vorteil: unglaublich viel schneller =)

    > Danke übrigens für das erste konstruktive Posting in diesem Thread.
    Mal ganz unkonstruktiv, aber nicht böse gemeint: im golem oder heise forum rumzunölen bringt selten was - insbesondere nicht bei allen Themen außer Politik ;-)

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Michelin Reifenwerke AG & Co. KGaA, Frankfurt am Main
  2. über SCHLAGHECK + RADTKE Executive Consultants GmbH, Ravensburg, Biberach, Sigmaringen, Pfullendorf
  3. Modis GmbH, Karlsruhe
  4. Haufe Group, Freiburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 27,99€
  2. 3,99€
  3. (-60%) 11,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Watch Dogs Legion angespielt: Eine Seniorin als Ein-Frau-Armee
Watch Dogs Legion angespielt
Eine Seniorin als Ein-Frau-Armee

E3 2019 Elitesoldaten brauchen wir nicht - in Watch Dogs Legion hacken und schießen wir auch als Pensionistin für den Widerstand. Beim Anspielen haben wir sehr über die ebenso klapprige wie kampflustige Oma Gwendoline gelacht.


    Final Fantasy 7 Remake angespielt: Cloud Strife und die (fast) unendliche Geschichte
    Final Fantasy 7 Remake angespielt
    Cloud Strife und die (fast) unendliche Geschichte

    E3 2019 Das Remake von Final Fantasy 7 wird ein Riesenprojekt, allein die erste Episode erscheint auf zwei Blu-ray-Discs. Kurios: In wie viele Folgen das bereits enorm umfangreiche Original von 1997 aufgeteilt wird, kann bislang nicht mal der Producer sagen.

    1. Final Fantasy 14 Online Report Zwischen Cosplay, Kirmes und Kampfsystem
    2. Square Enix Final Fantasy 14 erhält Solo-Inhalte und besonderen Magier
    3. Rollenspiel Square Enix streicht Erweiterungen für Final Fantasy 15

    Ada und Spark: Mehr Sicherheit durch bessere Programmiersprachen
    Ada und Spark
    Mehr Sicherheit durch bessere Programmiersprachen

    Viele Sicherheitslücken in Software sind auf Programmierfehler zurückzuführen. Diese Fehler lassen sich aber vermeiden - und zwar unter anderem durch die Wahl einer guten Programmiersprache. Ada und Spark gehören dazu, leider sind sie immer noch wenig bekannt.
    Von Johannes Kanig

    1. Das andere How-to Deutsch lernen für Programmierer
    2. Programmiersprachen, Pakete, IDEs So steigen Entwickler in Machine Learning ein

    1. Retro-Gaming: Star Wars für den Game Boy und NES wieder erhältlich
      Retro-Gaming
      Star Wars für den Game Boy und NES wieder erhältlich

      Limited Run Games bringt den Konsolenklassiker Star Wars in einer limitierten Edition wieder in den Handel - als Cartridges für den NES und den Game Boy. Für Vitrinenbesitzer interessant: Die Verpackung kann von der Rückseite aus geöffnet werden.

    2. BVG: Berlin bekommt eine neue Elektro-Buslinie
      BVG
      Berlin bekommt eine neue Elektro-Buslinie

      Mit der Linie 300 wird in Berlin eine neue Strecke für Elektrobusse erstellt. Diese wird zwar nicht ausschließlich mit E-Bussen betrieben, wird aber eine Linie mit Fokus auf den Elektrobetrieb. Wie die anderen 100er-Linien fährt auch der 300er an touristisch interessanten Zielen entlang.

    3. Falcon Heavy: Dreimal erfolgreich gestartet und dreimal abgestürzt
      Falcon Heavy
      Dreimal erfolgreich gestartet und dreimal abgestürzt

      24 Nutzlasten wurden erfolgreich ausgesetzt, allein drei davon zur Erprobung neuer Antriebe im Weltraum. Mit der Landung der Zentralstufe hatte SpaceX wieder kein Glück, aber eine Nutzlastverkleidung wurde auf dem Meer aufgefangen.


    1. 13:30

    2. 13:15

    3. 12:43

    4. 12:02

    5. 11:56

    6. 11:51

    7. 11:26

    8. 11:12