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. Universität Konstanz, Konstanz
  2. Landkreis Märkisch-Oderland, Seelow
  3. Dataport, verschiedene Standorte
  4. BWI GmbH, bundesweit

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Smartphones, TVs, Digitalkameras & Tablets reduziert)
  2. 139,99€ (Bestpreis - nach Abzug 20€-Coupon)
  3. 749,00€
  4. 199,00€


Haben wir etwas übersehen?

E-Mail an news@golem.de


WLAN-Kameras ausgeknipst: Wer hat die Winkekatze geklaut?
WLAN-Kameras ausgeknipst
Wer hat die Winkekatze geklaut?

Weg ist die Winkekatze - und keine unserer vier Überwachungskameras hat den Dieb gesehen. Denn WLAN-Cams von Abus, Nest, Yi Technology und Arlo lassen sich ganz einfach ausschalten.
Von Moritz Tremmel

  1. Wi-Fi 6 Router und Clients für den neuen WLAN-Standard
  2. Wi-Fi 6 und 802.11ax Was bringt der neue WLAN-Standard?
  3. Brandenburg Vodafone errichtet 1.200 kostenlose WLAN-Hotspots

IT-Sicherheit: Auch kleine Netze brauchen eine Firewall
IT-Sicherheit
Auch kleine Netze brauchen eine Firewall

Unternehmen mit kleinem Geldbeutel verzichten häufig auf eine Firewall. Das sollten sie aber nicht tun, wenn ihnen die Sicherheit ihres Netzwerks wichtig ist.
Von Götz Güttich

  1. Anzeige Wo Daten wirklich sicher liegen
  2. Erasure Coding Das Ende von Raid kommt durch Mathematik
  3. Endpoint Security IT-Sicherheit ist ein Cocktail mit vielen Zutaten

Gemini Man: Überflüssiges Klonexperiment
Gemini Man
Überflüssiges Klonexperiment

Am 3. Oktober kommt mit Gemini Man ein ambitioniertes Projekt in die deutschen Kinos: Mit HFR-Projektion in 60 Bildern pro Sekunde und Will Smith, der gegen sein digital verjüngtes Ebenbild kämpft, betreibt der Actionfilm technisch viel Aufwand. Das Seherlebnis ist jedoch bestenfalls komisch.
Von Daniel Pook

  1. Filmkritik Apollo 11 Echte Mondlandung als packende Kinozeitreise

  1. Ceconomy: Offene Führungskrise bei Media Markt und Saturn
    Ceconomy
    Offene Führungskrise bei Media Markt und Saturn

    Die Diskussion um die mögliche Absetzung von Ceconomy-Chef Jörn Werner sollte eigentlich noch nicht öffentlich werden. Jetzt wissen es alle, und es gibt keinen Nachfolger.

  2. Polizei: Hunde, die nach Datenspeichern schnüffeln
    Polizei
    Hunde, die nach Datenspeichern schnüffeln

    Spürhunde können neben Sprengstoff und Drogen auch Datenspeicher oder Smartphones erschnüffeln. Die Polizei in Nordrhein-Westfalen hat kürzlich ihre frisch ausgebildeten Speicherschnüffler vorgestellt.

  3. Ring Fit Adventure ausprobiert: Sportlich spielen auf der Nintendo Switch
    Ring Fit Adventure ausprobiert
    Sportlich spielen auf der Nintendo Switch

    Ein Kunststoffring als Sportgerät, vor allem aber als magische Verbindung in eine Abenteuerwelt: Mit Ring Fit Adventure veröffentlicht Nintendo eine ungewöhnliche Mischung aus Fitness und Fantasy. Golem.de hat sich in den Kampf gegen einen bösen Bodybuilderdrachen gestürzt.


  1. 18:00

  2. 17:26

  3. 17:07

  4. 16:42

  5. 16:17

  6. 15:56

  7. 15:29

  8. 14:36