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. Beckhoff Automation GmbH & Co. KG, Münster
  2. awinta GmbH, Region Süd-West
  3. TeamViewer GmbH, Göppingen, Stuttgart, Karlsruhe, Berlin
  4. LEW Service & Consulting GmbH, Augsburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 27,99€
  2. 4,99€
  3. 4,99€
  4. 3,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mobile-Games-Auslese: Magischer Dieb trifft mogelnden Doktor
Mobile-Games-Auslese
Magischer Dieb trifft mogelnden Doktor

Ein Dieb mit Dolch in Daggerhood, dazu ein (historisch verbürgter) Arzt in Astrologaster sowie wunderschön aufbereitetes Free-to-Play-Mittelalter in Marginalia Hero: Golem.de stellt die spannendsten neuen Mobile Games vor.
Von Rainer Sigl

  1. Hyper Casual Games 30 Sekunden spielen, 30 Sekunden Werbung
  2. Mobile-Games-Auslese Rollenspiel-Frühling mit leichten Schusswechseln
  3. Gaming Apple Arcade wird Spiele-Flatrate für iOS und MacOS

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

Autonomes Fahren: Per Fernsteuerung durch die Baustelle
Autonomes Fahren
Per Fernsteuerung durch die Baustelle

Was passiert, wenn autonome Autos in einer Verkehrssituation nicht mehr weiterwissen? Ein Berliner Fraunhofer-Institut hat dazu eine sehr datensparsame Fernsteuerung entwickelt. Doch es wird auch vor der Technik gewarnt.
Ein Bericht von Friedhelm Greis

  1. Neues Geschäftsfeld Huawei soll an autonomen Autos arbeiten
  2. Taxifahrzeug Volvo baut für Uber Basis eines autonomen Autos
  3. Autonomes Fahren Halter sollen bei Hackerangriffen auf Autos haften

  1. AT&T: Testnutzer in 5G-Netzwerk misst 1,7 GBit/s
    AT&T
    Testnutzer in 5G-Netzwerk misst 1,7 GBit/s

    Das Branchenevent AT&T Shape sollte die Filmindustrie für 5G begeistern. Oft wurden auf dem Gelände von Warner Bros. in Los Angeles bis 1,7 GBit/s gemessen.

  2. Netzausbau: Städtebund-Chef will 5G-Antennen auf Kindergärten
    Netzausbau
    Städtebund-Chef will 5G-Antennen auf Kindergärten

    Der Deutschen Städte- und Gemeindebund spricht ein Tabuthema an: 5G-Antennen auf Schulen und Kindergärten. Der Mast strahle nicht auf das Gebäude, auf dem er steht.

  3. Ladesäulenbetreiber Allego: Einmal vollladen für 50 Euro
    Ladesäulenbetreiber Allego
    Einmal vollladen für 50 Euro

    Nach und nach stellen die Ladesäulenbetreiber auf verbrauchsgenaue Abrechnungen bei Elektroautos um. Doch eichrechtskonform sind die Lösungen teilweise immer noch nicht. Dafür aber bei Anbietern wie Allego recht teuer.


  1. 19:45

  2. 19:10

  3. 18:40

  4. 18:00

  5. 17:25

  6. 16:18

  7. 15:24

  8. 15:00